Dan Sugalski wrote:In addition to the thread autolocking front end and debugging front end vtable functions, both of which can be generic, there's the potential for tracing and auditing front end functions, input data massaging wrappers, and all manner of Truly Evil front (and back) end wrappers that don't need to actually access the guts of the PMC, but can instead rely on the other vtable functions to get the information that they need to operate.
Not that this necessarily mandates passing in the vtable pointer to the functions, but the uses aren't exactly marginal.
Going back to the idea of generating these vtables on the fly (and caching them): each instance of a vtable gets a void* closure in the vtable itself,
so at a certain expense in extra vtables, one could hang a structure off
of that that includes a pointer to the original vtable.
Which I thought of, but that only allows for one layer of indirection, and doesn't allow the original vtable to hang any data off its vtable data pointer. (Which exists, and is there for that very reason) If you have two or three layers of vtable functions installed then it becomes difficult and time-consuming to find the right data pointer--if you allow the same vtable to be layered in multiple times (and no, I don't know why you'd want to) then it becomes essentially impossible.
Unfortunately the layers need to stay separate with separate data attached, so if we allow layering and don't forbid the same layer in there twice we have to pass in the pointer to the vtable actually being called into, so the vtable functions can find the layer-specific data.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
