Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example of when you'd need to, rather than simply writing a PMC class that inherits from some base? I'm having trouble thinking of an example of when you'd want to be able to do that... After all, since operator overloading and tying effectively _replace_ the builtin operations, what more does one need?
Well, other than Constant, we need to be able to put locking on shared PMCs. We'd like to add a debug trace to a PMC. We could even make any kind of PMC sync itself with an external source on access, though that's a bit of a pathological case.
Indeed, all of this can be done, however, by subclassing Ref. I think the reason this isn't sufficient is that we want to change the actual PMC into this new variant when it is possibly already in existence. Like my C<supplant> was evilly trying to do. Perhaps there's a way to get that working safely...
The issue is that the PMC's original vtable assumes (and should, IMHO be _able_ to assume) that it has total control over the PMC's data,
Well... I think I'll disagree here. The *class* vtable can assume this. However that doesn't mean that any random vtable function can.
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.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
