On Sun, 27 Aug 2000, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > For example, rather than:
> >
> > my int $intVal = 0;
> >
> > you would say:
> > my $intVal = 0;
> > $intVal->asInt;
> > Or possibly even:
> > my $invVal->asInt = 0;
> > for simplicity.
>
> 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.
>
> I'd rather than any "variables are represented by objects" magic
> be done behind the scenes.
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
my Foo $bar;
case would be that all the vtable functions for Foo are taken as specially
named subs/methods in the Foo package. So, for example, if you did:
print $bar;
then the core would vector through Foo's STRINGIFY sub, or if you did a:
$baz = $bar + 12;
the core would call Foo's ADD sub.
As a sort of handy side-effect, you get overload's functionality thrown in
as a gimmie, assuming things like math operators are part of the
vtable. (Which they probably will be, though once again no promises)
Default actions would likely be a fall-back to the 'base' operations or
generic failure, depending on the settings for your package.
Dan
