Re: RFC 161 (v2) OO Integration/Migration Path

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