On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to
avoid the complexity of
Really, the complexity of 'friend' comes from people abusing it.
In D, I would prefer no breaking change here. Leave private as
it is.
Just a simple attribute that only applies within a class, and
only to private members within that class.
@strictly private string firstName_;
Nothing outside of the class, not even the module, can access
this now. It's all encapsulated.
It breaks nothing (AFAIK).
It's very clear what the intention is here.
It's an easy attribute to remember.
It restores the principle of class enscapsulation within a
module, for when it's really needed.
Now D programmers would have the best of both worlds.
Why do you insist that you know how everything works and you are
the harbinger of truth. The fact is, you don't know squat about
what you are talking about and you just want to conform D to your
naive ignorant understanding of programming so you don't get
confused rather than learning and accepting D for what it does,
which is do everything better than C/C++. You keep trying to make
it in to C/C++, the the hell don't you just go use C/C++ then?
No one is going to listen to you. Your ignorance is pointed out
by many that have used D far longer than you have and you think
you can come in and point out all the things wrong without having
any experience with it.
The fact is, the creator of the class is also the creator of the
module.. and preventing him from having full access to the class
is ignorant. He doesn't need to encapsulate himself.
Encapsulation is ONLY meant to reduce dependencies. If the
programmer, probably someone like you, can't trust himself to
understand his own code then he shouldn't be coding.
If you don't like it, just write one class per module and don't
have any free functions... it solves your problem and it doesn't
use your shitty "solution". No one is forcing you to access your
class outside the class but inside the module.
The fact is you are ignorant of what you speak about and that is
99% of the problem. If you don't like how D does it, go use
another language that does it the way you "think"(if you could
call it that) is correct.
Many of the thing D does is learned from the mistakes of C/C++...
and for you to pretend that your insignificant self who has never
wrote a compiler much less read the specs has a clue about the
ramifications of the changes is moronic.
Your only reason for not liking it is because you "don't like
it"... how moronic.
"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.
"
Yet you have no clue... You "learned"(brainwashed" that
encapsulation means private members of classes cannot be accessed
from C++ and because D provides a more complex rule that you
can't seem to grasp(but which is very simple and no other human
that has used D has had issues with) you say that D is wrong
rather than that you or C++ is wrong.
The fact is, you are a moron. It's not because of this one issue
but because of your mentality of which this is just an example.
I'm sure you have the same thing with many issues in your life
and you go strutting around like you own the place telling
everyone what is wrong with how things are done when you yourself
have no clue.
Want me to prove it to you?
You say:
"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.
"
Yet, really, what you mean is that it breaks the concept of class
that you learned in programming 101 that had to do with C++. You
don't have a clue about logic and qualification. Maybe you are
confused and you thought D was C++?
You know, if you go to Rome... ah never mind, you won't get it...
