Boost logo

Boost :

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-05-31 20:14:02

On 2016-06-01 09:07, Emil Dotchevski wrote:
> ...
> That said, the most important feature of object-oriented design is data
> encapsulation, ...

I think it needs corrected. I am pretty sure it is "data and behavior
encapsulation"... and the "behavior" is something that you take out to
be free-standing functions and, actually, violate OO... just saying...
not that I lose sleep over it. :-)

>> ... I feel that it is unlikely to "fly" with "general programming
>> population". :-)
> Yes, I'm aware of that. It doesn't mean they have a point though. :)
> I just can't support including yet another can of worms in the already
> complicated name lookup/implicit instantiation/overload resolution
> process.

Look who is an orthodox zealot now!.. :-) So, even with understanding
that "general public" is unlikely to do it your way you are not to give
them anything else... Just saying... Not judging... :-)

> A compromise would be to allow the definition of non-friend members,
> like
> this:
> struct foo;
> void foo::do_something();

Indeed, that'd be handy to support your pimpl style. I just suspect it
violates encapsulation and, well, it's just not in the language.

> This language change seems a lot safer than messing with the overload
> resolution. Perhaps I'm wrong. Either way, I don't consider "but I want
> to
> use the dot syntax" a very compelling argument.

I do not feel it is as dumb as "but I want to use the dot syntax". I am
beginning to feel that

1) you break the "data+behavior" encapsulation (by taking the methods
out) and we reap the immediate benefits of reducing pimpl to mere
shared_ptr; exciting;

2) now if I want to bring that "data+behavior" association back, I'll
use notional (rather than actual) association wrapping it all in a
namespace; why not;

3) after reading the thread I am under impression that as the
deployments are getting more complex I need to introduce accessibility
(private, public) qualifiers... and the impact of #1 is becoming more
apparent as (due to language limitations you might say) we have to
re-introduce the broken "data+behavior" association via "friends". That
is we seem to be drifting back where we started... but in an
unconventional way... which I am not sure will be eagerly embraced. :-)

Boost list run by bdawes at, gregod at, cpdaniel at, john at