On June 6, 2014 4:59:47 AM EDT, Vladimir Batov
I am looking back and trying to figure out how my deployment was/is so different from what [Gavin] and Andrzej would use Pimpl for. Now that I am thinking about it seems to always play a role of a (shared) handle to some big chunk of data. Not just bit chunk but mostly read-only and non-copyable.
There's nothing wrong with such an implementation.
So, for me the implementation-hiding property of Pimpl would always go hand-in-hand with the proxy/handle property...
That's where you go off-track, so to speak.
For some reason I always assumed many Handles in the Handle/Body idiom... which Pimpl is just another name for.
Another step away...
Now that I am researching Handle/Body, Bridge they are about decoupling of an abstraction from its implementation. No explicit mention of "shareability" of the implementation. Seems like Rob was right saying I inadvertently "extended the idiom"...
:)
On the other hand all the Handle/Body, Bridge, etc. descriptions I've read so far indeed do not mention "shareability". However, they do not say that "shareability" is *not* part of the idiom either. To me it makes sense because Handles are cheap.
Making such a lap is not a problem. Continuing to call what you're doing by the same name is the problem. What you're doing is COW, at least if writing the underlying data triggers a copy. (If not then I'd say you're providing a variation of the Flyweight Pattern.)
So, having many Handles for one Body does not seem like such a huge leap.
No, it doesn't.
In that light, my offering of pimpl::pointer_semantics and pimpl::value_semantics seems to make sense.
That's the problem. It isn't the Pimpl Idiom anymore. ___ Rob (Sent from my portable computation engine)