Combinatorial explosion. This already requires four variants (normal, const, threadsafe, const threadsafe), and we haven't even seen what real users will want to do with PMCs yet.
Not quite. A const PMC is already thread-safe.
Hmm, good point. (I guess you can't set properties on a const PMC, right? Might we want to, for internal purposes like caching expensive-to-calculate data?)
... (I could imagine, for example, people wanting to push a transcoding layer onto a string or aggregate PMC, which forces all incoming strings into a certain encoding. Or a layer that lowercases incoming keys. Or, or, or...)
These layers are implemented at the IO level as I/O layers.
Indeed. I just think that the idea can be extended beyond I/O to all PMCs.
> If such a
layer should really be PMC specific, it could be implemented as a distinct object.
Absolutely. But if all I want is something that makes any string-indexed aggregate case-insensitive, why should I have to code a bunch of brand-new PMC types? Pushing a layer on top of the existing types makes more sense.
There are other cases like this, too. For example, imagine a layer that transparently compresses strings passed to set() functions, and then decompresses them when they come out through get() functions. This could be useful with any disk-backed PMC, like a DBM hash, or simply used to save RAM (assuming you have a few very, very large strings). Once again, why force you to customize a bunch of PMC types when you could write it once and push it on as a layer?
Can this be done with special subclasses? Sure. But if we do it with a true layering system, we get an incredible amount of power essentially for free.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
