Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2011-05-26 23:06:54

> Krzysztof Czainski <1czajnik <at> gmail.com> writes:
> ...
> Personally I think the proposed Pimpl library tries to solve too many things
> at once. 

On the bigger scale it tries just *one* thing -- to implement the Pimpl idiom as
it is understood by me (which might well be misunderstanding). On the smaller
scale it tries to do *two* things -- 1) the separation of interface and
implementation and 2) implementation hiding. It is because that is how I
understand the properties/qualities/characteristics of the Pimpl idiom. What
exactly more does it do? Is it the relational ops you do not like? Then, say,
shared_ptr has them and one needs them if a Pimpl-based class is to be used,
say, in std::containers. Is it null() that keeps you awake at night? Then, many
classes (like shared_ptr again) have it... maybe not in as explicit form but
still. Is it the support for the Bridge pattern and Non-Virtual Interface Idiom
that get you worried? Then, ignore that -- that's not a stone in your shoe, is
it?

> Individual use cases might want those, not care about them, or
> specifically not want them.

So, if I follow your line of reasoning correctly, then I should discard
boost::regex as it provides support for

    Perl Regular Expression Syntax
    POSIX Extended Regular Expression Syntax
    POSIX Basic Regular Expression Syntax

when I only "want/care for" the Perl syntax? Do you pay for that additional
functionality? Is it heavy to carry? Is it getting in your way somehow? Does it
result in unexpected behavior? Have you noticed that *any* library actually
provides *more* than *you* usually need because such library might be written
with wider audience in mind? Jeez, I do not believe we are even discussing it!

> ...
> And Pimpl providing the following:
> safebool operator;
> pimpl::null;
> can be an unwanted side-effect, and may therefore lead to a decision not to
> use the proposed Pimpl in this case.

Are you just pondering or have something concrete in mind? If that is the
latter, then bring it on. We'll look at it and fix it... or I'll say, shit, you
are right, bad-bad design... and fix it again. Otherwise, all these "can" and
"may" are just noise.

> Many of the features addressed by Pimpl can be provided by separate tools,
> instead of packing all of them to Pimpl.

Yeah, and next time you go to buy, say, a car, please to not accept a car as a
whole but insist on wheels, radio, etc. separately. I am sure you'll enjoy the
ride.

> ...
> To conclude, I agree, that the problems addressed by the proposed Pimpl need
> solutions, but I suggest providing separate tools addressing the problems
> instead of Pimpl addressing all of these. 

So, would you please come forward and suggest something tangible addressing
those problems. I am sure you are prepared that that features that you care
about might not be so dear to somebody else's heart.

V.