On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
If you have
sealed class A {
private {
// members
}
}
Then you can't use the defualt 'private' if you need it for a
specific member.
But if sealed is an access type of a member, 99% you will use
sealed insted private in a class, so it is not redundant.
class A {
sealed {
// members
}
private int friendMember;
}
And you use private keyword only if you need to access that
variable from a class/function/struct.. in the same module,
like a friend.
I agree. But then we end up with what D should have implemented
in the first place - C++ friends ;-)
(and in fact, quality software development should rarely, if
ever, require the use of friend (which is just a managed way of
breaking encapsulation - but, its managed, and managed by the
programmer explicitly).
But in D, everything is your friend - you don't get to manage
anything - which even to the dumbest of us, must suggest some
impact on the quality of the software that will get developed in
D. So, now, we need to consider absurd coding standards to get
around this facebook style friendship problem (like implementing
the proposed 'one class per module' crap - and btw. that is the
purest form of OOP - so D actually forces you into this purest
form of OOP - even other mainstream OOP langauges don't force
that on you).
There is absolutely no reason why D cannot have both (the current
way D does it, and the C++ way). It's obviously technically
possible. It's obvious it would attract a great deal more
programmers to D. It doesn't really complicate the language at
all - that's just an excuse not to change. And, it's obvious,
that protecting the interface would result in better quality
software. It's a core fundamental principle of quality software.
It's just a matter of getting more diverse people into the D
'community'.
But I get the feeling that's not what most D people want. The
status quo is pretty comfortable for many, it seems.
Maybe in decade time, if/when D v3 comes out. But I won't be
holding my breath.
