Brent Dax <[EMAIL PROTECTED]> wrote: > Okay, reality check. How often are we going to use acosh? Is it really > worth the space in the vtable for that few calls? And why can't we just > use find_method?
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. WRT methods: I did propose a scheme, to implement trig and log methods via find_method, even with a rather low overhead of one *Array* lookup. Doing an hash lookup still suffers badly as shown in the constant key/string discussion, but would be possible too - if needed. > I'm really starting to wonder: why do we have only one type of vtable? > Why are Closures, Pointers, and Scratchpads forced to implement acosh, they won't. > 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 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. > And: > pmc->vtable->add_keyed Forget add_keyed ;-) > --Brent Dax <[EMAIL PROTECTED]> > Perl and Parrot hacker leo
