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.

Reply via email to