Dan Sugalski wrote:
>
> 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.
But this shouldn't necessarily be Foo::ADD, right?
my Foo $foo = BlueFoo->new();
print $foo + 3;
should call BlueFoo::ADD, not Foo::ADD, no? (where BlueFoo isa Foo). But
if so, then it seems like my Foo $x and my Bar $x are equivalent -- both
of them just mean "use my actual class to look up vtable methods", maybe
with some type checking to ensure that only subclasses of the declared
class are put into $x. But then what does my $x = BlueFoo->new(); print
"$x" do, assuming there is a BlueFoo::STRINGIFY? Print
"BlueFoo=HASH(0x0b38134)"?
As for non-vtable methods, were you planning on making
my Foo $foo; $foo->method_not_in_Foo_package();
a compile-time error?
