(Forgot to send this to the list. Again. *sighs*)
Dan Sugalski:
# Okay, since it seems reasonable to hang the trig functions off of
PMCs,
# we'd best get a list of the functions we want. I can think of:
#
# pow
# logarithm
# square root (yes, I know, it's for speed)
#
# Normal and hyperbolic versions of:
# sine
# cosine
# tangent
# cotangent
# arcsine
# arccosine
# arctangent
# arccotangent
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?
Basically, where do you draw the line between a vtable method and a
find_method method? Unless the line is "methods that everything should
support", I'd say it's been crossed when you add acosh to the vtable.
And if that *is* where the line is, don't be surprised when vtables
cross the megabyte line.
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,
splice, pop, or even get_float? And why are PerlInts forced to
implement invoke and can_keyed?
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.
The result would mean that something like:
pmc->vtable->add
Might become:
pmc->vtable->math->add
And:
pmc->vtable->add_keyed
Might become:
pmc->vtable->keyed->math->add
This would make it easier to implement non-keyed objects, and the extra
dereference would be lost in the overhead of dealing with keys and
aggregates anyway.
Best of all, if a PMC class doesn't need math calls, it can simply put
this in its vtable definition, in place of the curlies delimiting the
set of math calls:
&Parrot_pmc_default_math_vtable
--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."
