Front page | perl.perl6.internals |
Postings from February 2001
Might this be madness? (BRAINSTORMS AHEAD!):
The API of the Perl data types could be specified
in the following way:
*) a class hierarchy (hopefully not a deep one).
eg.
AnyV (XV?)
|
-------------------------
| | | |
SV AV HV ...
...
*) for each class a list of preproc. macros which may (only) be called
for this class and its derived classes.
eg.
SvPLUS(SV * this,SV * arg)
The type-checking would, of course, be done on the expansion of the
macro :-(
PROS:
+ The macros will be defined for convenience anyway, I guess.
+ If -- in a later phase of design/implementation -- it proves to be
better to remove a function from the vtables it could be turned into
a static function or mapped to another virtual function (eg. PUSH -> SPLICE)
without changing the callers of the function. (Of course *not* without
recompiling the calling code :-( I'm starting to think it *is* madness.)
+ There could be (dirty?) inline optimizations for special cases.
(Only makes sense if CALLs are quite expensive.)
+ The virtual function dispatch could be done for any argument
of the macro, not only for the first.
CONS:
- This scheme could become a mess, if abused.
- Binary compatiblity for extensions would require extremely strict version
control of the macro definitions. (If they are kept together with the
vtable definitions this is probably not a problem.)
(There could also be wrapper functions.)
INDIFFERENCE:
. I think debugging would not suffer much, if there are not too many
inline optimizations, because most macros will expand to a single
unconditional line of C-code.
-Edwin
Thread Next