At 10:46 PM 8/31/00 +0000, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > Okay, here's a list of functions I think should go into variable vtables.
>
>All the math functions are in here. Can the entries that my type does
>not use be replaced with other functions that my type does use?
That's what overloading does.
> > Functions marked with a * will take an optional type offset so we can
> > handle asking for various permutations of the basic type.
>
>
>These aren't going to be that huge then, with each one taking *void()
>thismuch[30]
>or so; why don't we skip the "optional offset" and make subclasses keep
>their whole own copy? Will 240 bytes per type blow out a modern cache?
Nope. When I said optional offset, I meant that the version of perl you
were using might or might not have the capability to do this, depending on
compile-time options.
> clarify (where does this type go to resolve uncached method names?)
>
>or is that better kept in a global clarifier that keeps it's own mapping.
You're confusing perl-level objects with these low-level internals things.
This stuff isn't really visible except to people writing new variants on
base perl types, so you won't see it unless you're writing overload code.
>I think the list is too long, for the base type. Could the base type be
>something that just knows how to return its type name, in order to build
>types that do not have defined STRING methods?
We're shooting for speed here. Any common operation that could be affected
by the type of the variable should be represented so a custom function can
be called that does exactly what needs to be done.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
