Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-05-29 23:16:24

Gavin,

Apologies for top-posting... I feel that you make very ambitious 
generalizations about how users will feel and how ugly in your view the 
code will be of those who might decide to use the proposed pimpl. I hear 
your view and I respect it. I just do not happen to share it. No drama. 
we are all different.

So, in your view, should we try and have pimpl in Boost? I think we 
should as it'd be useful IMO. I proposed the one I use. I am not married 
to it. If you have a design which makes you happy, let's consider it... 
Otherwise, we won't get far on criticism only without alternatives to 
consider. Don't you think?

On 05/30/2016 12:32 PM, Gavin Lambert wrote:
> On 30/05/2016 13:20, Vladimir Batov wrote:
>> You are right. It can't be inside a "namespace chart { namespace panel
>> {" block... and I personally never expected it to be. After all that's a
>> specialization of (assume Boost)
>>
>> namespace boost
>> {
>>      template<typename user_type> pimpl { struct implementation; }
>> }
>
> Right.  And to users, this is going to feel like defining their types 
> (at least the private members, possibly even some method 
> implementations) inside the boost namespace -- and that feeling isn't 
> entirely wrong.
>
>>> If you have the convention that these blocks span the file, it means
>>> you either have to put such specialisations at the top or bottom of
>>> the file outside the namespace block (which may break locality) or you
>>> have to close the namespace blocks and reopen them later (which is 
>>> ugly).
>>>
>>> (Imagine the case where you want to define some detail classes that
>>> only exist in the implementation *first*, then the pimpl definition,
>>> then the public interface.  The first and last should be in the local
>>> namespace [or child thereof]; the second can't be.  And they have to
>>> be defined in that order due to the dependencies.)
>>>
>>> Granted implementation files don't *have* to have namespace blocks --
>>> they can use using directives or explicit naming instead; but the
>>> latter is ugly and the former risks accidentally defining global
>>> symbols, so it's generally safer to use namespace blocks instead.
>>
>> Yes, I understand. You have your personal programming style and you feel
>> the suggested pimpl does not fit that style as well as you'd like it to.
>> I respect that. But I do not see it as a principal objection... is it a
>> principal objection?
>
> I don't think it's a personal programming style issue.  I think it's a 
> natural consequence of writing code in the non-global namespace.
>
> I suppose you could consider writing code not in the global namespace 
> as a personal style choice, but at least for library code (which is 
> the most likely to want to use pimpl style so they can avoid ABI 
> breakage with applications) this is the encouraged style.  Certainly 
> most (all?) of STL and Boost is itself not in the global namespace.
>
> So (at least in my opinion), the primary users of Pimpl will probably 
> be library developers who want to write code in custom namespaces.  
> But they can't use Pimpl without breaking out of their namespace and 
> writing some code in the global/boost namespace instead.  This is a 
> code uglification that seems like it should be a principal objection 
> -- if that doesn't count, what does?
>
> (Some app authors will want to use Pimpl as well of course -- which 
> has the same issues if the namespaces don't match.)
>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost