I've read over 161 again and I'm starting to see areas where I can clarify
things greatly. I apologize for the confusion.  I'll make mods to the RFC in
the near future, after I get more feedback from you all.

Here are my goals as they probably should have been stated in the RFC:

- Concentrate responsibility closer to the basic data structures (currently
scalar, list, and hash).
- Allow customization of these structures by the user, though inheritance.
- Reduce or eliminate the need for new keywords in Perl itself, since the
basic data structures can be extended as needed.
- Maintain a migration path for Perl 5 (so I can have all of this without
touching my existing code).


> I shudder to think of something that prevents simple variable accesses
> and instead requires verbose method calls.  That doesn't seem to be
> making anything easy.

Ditto. Accessing data doesn't change. I'm not suggesting accessors be added
to scalars. Rather, I'm suggesting that scalars be responsible for knowing
their type, rather than Perl being responsible for that. Methods like
'asInt()' are intended to act as a switch that gets flipped so the scalar
knows what type it is supposed to be. Optionally, they could also act as a
cast mechanism when used as an rvalue. An overloadable cast mechanism at
that.


> Do you mean that when we write:
>
>   my int $intVal = 0;
>
> it gets turned into OO stuff?  Or do you mean that we won't be
> writing
>
>   my int $intVal = 0;
>
> any more?  I don't like the latter option.  It would seem to require
> more typing to allow something that a minority of people will use.

Originally I was trying to avoid explicit typing through new keywords, like
'int'. So the latter option would have been the case. But after Nathan
Wiger's reply to my RFC, I realized that either syntax would work. Under one
scenario, 'int', as in your example, would simply be the name of a factory
function, so that:

   my int $intVal = 0;

could be equivalent to:

    my $intVal = Scalar->int(0);

And with no more typing required than before.


Matt

























Reply via email to