At 02:29 PM 9/29/00 +0100, David Mitchell wrote:
>Regarding the tentative list of vtable functions:
>I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
>The danger with these is that they may impose a single implementation
>of scalars upon us.
>
>As an example, suppose I wrote an alternative scalar implementation that
>was optimised for many small string appends followed by a single get
>of the wholpe string at the end. (I might internally do this with a linked
>list of blocks, say; then allocate a single large block at the end to
>return the whole string.)
>
>If sv1 is a standard SV and sv2 is an append-optimised one, then
>
>(sv1->vtable[IS_EQUAL])(sv1,sv2) would crash and burn, because
>sv1's 'is_equal' function doent know that sv2 has a different internal
>representation.
Your worries are well-founded, but ultimately not a problem. (I do like
those kinds... :)
Since the generic internal representation of a variable is hidden from
anything but that variable's vtable, the scenario you propose can't happen.
What'd happen instead for a plain ASCII string compare would look something
like:
bool is_equal(pmc1, pmc2) {
if (strcmp(pmc1->string, to_string(ASCII, pmc2)) {
return Perl_FALSE;
} else {
return Perl_TRUE;
}
}
Overloading does present an ordering issue, and one I am worried about. It
either requires all the vtable functions to know about all the variable
types (which is impossible, unfortunately) or it means perl needs to
dynamically reorder the operation so the 'bigger' variable's function gets
called.
Reordering's also not a 100% panacea--it's fine for ops involving a base
type and an extended type, but it can potentially break down with two
extended types. (What happens when you add a complex number with a complex
bigint, if the two types have no idea about each other?)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
