On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote:
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit
wrote:
Mmm.. I don't think I like it.
I feel you should be able to make a member of a class,
private, regardless of where the class is located. This seems
to break the concept of class encapsulation.
No. I don't like it at all.
If you have access to the module source, you have access to
the source of types inside it. Making the module the lowest
level of encapsulation makes sense from that perspective.
There are two problems I see:
1st - D has broken the concept of class encapsulation, simply
for convenience at the module level. Not good in my opinion.
2nd - C++/C#/Java programmers will come to D, use the same
syntax, but get very different semantics. Not good in my
opinion. (i.e. I only realised private was not private, by
accident).
D has made many good design decisions. I do not see this as one
of them.
There is another problem:
3rd: You are a brainwashed monkey who can't think for himself.
See, You learned a little about C++/C#/Java and think the world
must conform to what they say is correct and deny everything that
contradicts it rather than first seeing if you are on the wrong
side of the contradiction.
The fact is, there is no reason a module should be restricted to
see it's own classes private members.
It's sorta like a family who runs around pretending that they
can't see each others private parts. Sure, it sounds like a good
thing... until someone accidentally drops the towel and the
offended calls the cop on their brother and has him arrested for
breaking the law.
You should learn that your view of the world is very minute and
stop trying to fit the world in to your box. It's called growing
up. If you can't make a distinction between C++ encapsulation and
D encapsulation you have far bigger problems than you think.
