"Bryan C. Warnock" wrote:
> 
> On Thu, 10 Aug 2000, David L. Nicol wrote:
> > Within a perl instance, every object type must register itself on
> > loading.  At registration, a number is assigned, the jump table
> > of common functions that that object type overloads is filled, and also
> > a pointer to the association for uncommon methods of the object type
> > is filled. So the defined type table is an array of constant-sized
> > items.
> 
> How does this work with inheritence and the ilk?
> 
> --
> Bryan C. Warnock
> ([EMAIL PROTECTED])


inheritance becomes duplicating the parent class's vtbl entries
according to the declared ISA.

long late binding based on function names (what perl5 has) would
still be available as a fallback case, and AUTOLOAD would append
to the table of all the classes that load the function.

Lets say D isa C isa B, and an undefined method f is called on D,
which can be loaded on B.


f was not linked in at compile time as something D was expecting to
have to do, so perl must determine its ability to perform D->f late.


D finds that there is no mapping for f in its vtbl, D->AUTOLOAD(f)
fails, check's D's @ISA container and finds C listed there, calls
C->AUTOLOAD(f) which does the same and calls B->AUTOLOAD(f) which
discovers that it not only has a definition for f but knows right
where it is in the store room, and runs down to get it. Perl then
compiles (whatever that means -- I want them to go all the way to
something that ld(1) would know what to do with but I may be a radical
fringe) B's definition and returns the entry point E to B, which makes
an entry $B->vtbl{f} = E, and passes E to C, which makes an entry
$C->vtbl{f} = E, which passes E to D, which makes an entry $D->vtbl{f}
and then returns a success code from AUTOLOAD and retries f.


That gives fine control on the part of the child as to which of
competing versions of methods with the same name they want to inherit,
as their own vtbl is ultimately under their own control.

One sneaky thing would be if a parent changes their method after a
child has bound it, does the child need to check that the entries 
match, or does the child need to keep careful track of what methods
might change during a run, so they can be updated?

Redefining a method during run time --- is that even a feature that
needs to be supported?



-- 
                          David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq

Reply via email to