Leopold Toetsch: # Dan was talking about one vtable slot, holding another vtable for trig # and log functions. The newly added vtable->data seems to be that. This # trig_log (or data) pointer is shared by all scalar classes. So that # takes one additional pointer per vtable and one additional trig_vtable.
I didn't catch this bit before. # > Vtable.tbl already divides vtables into sections. I suggest we take # > this a step further and express these sections in the vtables itself. # > Sections that a particular object didn't need would be loaded with a # > default, in which all of the methods would throw an exception. # # That's what happening anyway. All unimplemented stuff has a default hook # throwing an exception. The indirection would allow for a default set. It's the difference between eight default pointers per vtable (to default sections) and eighty default pointers (to default implementations). If there are a lot of PMCs that use several sections of defaults (and this seems to be the case), it's a win spacewise. # > The result would mean that something like: # > pmc->vtable->add # # > Might become: # > pmc->vtable->math->add # # Seems too expensive to me for the normal math stuff. Perhaps, although one dereference doesn't seem to painful to me. Since we are doing trig in another section--I didn't catch that before--it seems that this'll be okay. However, I do encourage everyone to consider whether we should only be putting trig in separate tables, or if we should be putting other methods too, as I've proposed. --Brent Dax <[EMAIL PROTECTED]> Perl and Parrot hacker "Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it."
