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, so there is nowhere in the PMC to put a lock or a handle to an external source or anything. So you'd either need a Ref of some sort anyway or a global lookup table, which seems to be an even worse idea.
Debug tracing, though, is a good question... I hate to pass an extra pointer to every vtable call just for that, though...
-- BKS
