At 11:28 AM 8/28/00 -0700, Steve Fink wrote:
>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?
Yes. (Assuming BlueFoo->new returns a variable blessed into BlueFoo, of
course) Presumably each package will have a prebuilt vtable attached to it
that gets smacked into any variable marked as blessed into it.
> (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.
More or less, yep. It'll get funkier for builtin types, I think--if you do:
my int %somehash;
then stick a non-int into a hash entry, %somehash will probably get
promoted to a full scalar hash rather than an int one.
>But then what does my $x = BlueFoo->new(); print
>"$x" do, assuming there is a BlueFoo::STRINGIFY? Print
>"BlueFoo=HASH(0x0b38134)"?
That's a good question. Not my call--that's language design. (Says the man
neatly ducking the issue... :)
>As for non-vtable methods, were you planning on making
>
>my Foo $foo; $foo->method_not_in_Foo_package();
>
>a compile-time error?
Also a language issue. There are AUTOLOAD things to take into account,
amongst other things.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
