From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> "Mark J. Reed" wrote:
> 
> > But you're opening a big can of worms if you make such a
> > change.  The biggest impact would be in the way methods are defined.
> > Instead of just being members of a package, they would have to be
> > associated with particular objects (classes or instances).  A method
> > may still be associated with a class by being defined in its
> > package, but what about an instance?    Do we give each
> > instance a package?
> 
> Rather, How Do We Do This With Vtables?

Aren't lexical subroutines on the table for Perl 6? Wouldn't they be well
suited for the task? And how do lexical subroutines hook in with vtables?


> I've been saying all along that I think class method names should get
> a number the first time they appear, which is the offset into the
> vtable (array of coderefs) for that name.  That would turn 
> the multiple hash lookup of current perl method binding into a single
> array lookup.

I'm still wishing people would consider having a separate namespace for
versions of classes. So that depending on module dependencies I could
simultaneously use modules with conflicting dependencies that require both
SOAP::Lite v0.50 and SOAP::Lite v1.X.

 
> So every class has a vtable, which is a copy of its parents except for
> what is overridden within it, and a instance that wishes to 
> deviate could make a local copy of its vtable and twiddle it.

Why not just fall back to the ancestor(s) unless it provides its own. What
good does flattening an instance accomplish that polymorphism doesn't?

Reply via email to