While I'm all for the macros (yeah, I know, debugger stepping issues and all)
I don't get that. What debugger issues? I changed some vtable calls in the iterator code and didn't see any differences during debugging. The macros just rearange the order of function arguments.
... I'd rather this be:
VTABLE_getprop(...
rather than
VTABLE_1(getprop,...
because the latter form doesn't give us much of a boost when put getprop behind a layer of indirection in the vtable, or something like that.
Well, hmmm - yes. I had this in mind of course (var/value vtable split) and must have lost the consequencies on they way somewhere :)
Including the vtable method in the macro leaves all the flexibility we need, in which part of the vtable, the function actually will reside. And shuffling them around will be easy too.
What about all the currently unused functions. Changing .*vtable.* in the whole tree seems to be less work, when we concentrate on used code. If really someone comes up with an efficient scheme of _keyed access everywhere, we can reinclude them - though I doubt that.
Finally, I had an implicit first argument "interpreter", which possibly should be in the macros explicitely for more flexiblity.
leo
