develooper Front page | perl.perl6.internals | Postings from February 2001

Specifying vtable API in terms of macros?

Thread Next
Edwin Steiner
February 3, 2001 08:01
Specifying vtable API in terms of macros?
Message ID:
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).
	        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.
	SvPLUS(SV * this,SV * arg)

   The type-checking would, of course, be done on the expansion of the
   macro :-(

+ 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.

- 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.)

. 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.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About