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?
> 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?
> type
> name
> get_bool
> get_string *
> get_int *
> get_float *
> get_value
> set_string *
> set_int *
> set_float *
> set_value
> add *
> subtract *
> multiply *
> divide *
> modulus *
> clone (returns a new copy of the thing in question)
> new (creates a new thing)
> concatenate
> is_equal (true if this thing is equal to the parameter thing)
> is_same (True if this thing is the same thing as the parameter thing)
> logical_or
> logical_and
> logical_not
> bind (For =~)
> repeat (For x)
>
> Anyone got anything to add before I throw together the base vtable RFC?
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.
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?
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Kansas City Perl Mongers will meet Sept. 20th at 7:00 in
Westport Flea Market Bar & Grill http://tipjar.com/kcpm
