At 04:12 PM 25/04/2001 +0200, Bart Lateur wrote:
>On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
> >If the idea is supporting arbitrary add-on operators...
>
>I think I second that. I would think of a fixed table for the built-in
>ones, and a linked list for the add-ons. It's not necessary that a new
>node is added for each and every method; instead, a structure similar to
>those used in TIFF files could be used, where each linked in node
>contains a table with several items, and a new node is only added when
>that table is full.
Actually, I thought about something like an entry in the vtable that is
like a method that takes an operator and returns an operation to act on the
operands. Something like:
struct xxx_vtable {
// ...
int (*OPERATOR_FALLBACK)(operation *result, xxx *this, char *operator);
};
struct operation_vtable {
// ...
void (*CALL)(xxx *result, xxx *left, xxx *right);
};
One that wants to call operator "theta" on something of type "xxx", would
call the OPERATOR_FALLBACK on the xxx object. If the object implements
"theta", it would write the resulting operation to "result" and return a
true value, like 1.
Then, with the result (that is of class operation), one would call the
method corresponding to the CALL entry, passing the xxx object as the left
argument, and possibly passing a right argument of class xxx, if the
operation is supposed to be a binary one. The result would be saved on xxx.
In the terms of the mail I wrote that started this thread, "xxx" would be
"sval".
Who implements the lookup, be it through linked lists, like you suggested,
or through hash-tables, or whatever, is the OPERATOR_FALLBACK operation.
It's free to choose whichever data structure it likes best.
- Branden
