On Monday, 22 January 2024 at 23:01:54 UTC, Walter Bright wrote:
On 1/21/2024 3:51 AM, zjh wrote:
When you need `friend`, You can put them all in one module.
Sometimes, when `multiple classes` are closely related and
independent, `class level privacy` becomes very important. No
one wants , someone from outside may secretly steal money from
your home.
D does not allow a different module accessing private class
members. Private access is limited to the module enclosing that
class.
This encourages a different use of modules than C++ "toss code
randomly into different source files."
These are redherring arguments against a robust principle of OOP.
A private attribute within a class (visible only to that class)
does not mean people can now go and 'toss code randomly into
source files. Nor should it be compared to people wanting
'non-constant const, impure pure, and GC allocating @nogc.'
Nor would it require D adopting the C++ notion of friends. (all
source in a D module is already the D like friend feature anyway,
it just implicit).
Nor should it be classified as a 'bad' feature because of
maintenance costs.
Nor is it an argument that D move away from module level privacy.
These are all redherring arguments.
There doesn't seem to be any real technical reason as to why D
should not allow that option. Swift has done this successfully
(for example).
There are only ever redherring arguments put forward, along with
the usual 'we don't do it that way in D' argument.
I'm not here to argue for the feature anyway. But given the
importance of class-private in OOP, I'd just like to see much
better thoughtout arguments against it. (i.e
technical/engineering arguments, not the fluff that always
accompanies this topic.
Putting everything into there own source files, and this includes
unittests of course (since they too can end up inadvertingly
testing the wrong part of a class), is a solution - but a
solution for some, but not others.
Anyway, this topic really belongs elsewhere now. But if/when it
does popup again, can we please hear better arguments against it,
rather than the fluff above, which is not at all convincing.