On June 6, 2014 8:21:19 PM EDT, Vladimir Batov
Rob Stewart-6 wrote
If one accepts the assertion that the Pimpl Idiom is the Bridge
the conclusion is appropriate. I don't accept the assertion. That is,
Pattern, the
Pimpl Idiom is the degenerate case, but it isn't the same as the Bridge Pattern.
Rob, if I understand correctly, you concede that my offering of "pointer_semantics" and "value_semantics" is appropriate *if* it was called "bridge" rather than "pimpl" because you assert that my-pimpl == bridge and real-pimpl == my-pimpl:value_semantics. In other words, "real pimpl is a subset of bridge, a coincidental bridge, a degenerate bridge", right?
Yes. I should go re-read GoF's description of Bridge and Coplien's description of Handle/Body. It's been a lot of years since I last did so.
Here we have no choice but go and ask H. Sutter as it was him who popularized Pimpl and wrote quite a bit about it.
1) http://www.gotw.ca/publications/mill04.htm 2) http://www.gotw.ca/publications/mill05.htm#1 3) http://herbsutter.com/gotw/_101/
In #1 Sutter introduces Pimpl as "a special form of the handle/body idiom (what I call the Pimpl Idiom...";
Saying it's a special form already implies differentiation.
Then in #2 he reiterates again that "This is a variant of the handle/body idiom."
Ditto for "variant".
So far, it's not exactly clear who is correct in our interpretations of Pimpl because loosely "variant" might be interpreted as "subset"... although strictly speaking "variant" means "modified" (http://thesaurus.com). In earlier Sutter's writings I certainly find those constant references to the Bridge pattern quite unfortunate... *if* that similarity is purely incidental. Maybe it was done for educational purposes. And, indeed, in his later writings Sutter seems to drop mentioning Bridge and exclusively stressing Pimpl being the Compiler Firewall idiom.
I find no inconsistency or room for confusion. Pimpl implements a degenerate form of the Bridge Pattern, but it isn't the same as other variants of the pattern. Therefore, calling all variants by the name of one degenerate variant is the problem. [snip]
All that said, now I am beginning to wonder if that's a good idea to even try getting "my-pimpl" into Boost.
I've never shared the implementation of a class among instances, apart from COW or Flyweight contexts, to my knowledge. I'm uncertain whether your shared mode supports those better than, for example, shared_ptr or custom solutions, but that doesn't mean it isn't useful, since you've been using it for years. There seems no clear interpretation
(in our *collective* mind) of what Pimpl embodies, what is Pimpl and what is not. More so, from reading #3 I conclude that Sutter advocates a far(!) simpler deployment pattern than I am offering. IMO all that uncertainty and controversy do not bode well for the code wishing be a part of Boost.
As I noted before, if you name your library Bridge, and it offers both pimpl and, say, shared_bridge class templates, the functionality remains and the confusion is lessened (at least for those that have never associated sharing with Pimpl). You could go with bridge::value_semantics and bridge::pointer_semantics, if you really want to, but I don't think that's as nice. Then again, using aliases mean you can offer both. IOW, I suggest that you postpone the review, rework your library, and then offer it for review. ___ Rob (Sent from my portable computation engine)