On Thursday, 9 February 2023 at 23:05:35 UTC, Hipreme wrote:
On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide
wrote:
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli
wrote:
On 2/8/23 04:07, zjh wrote:
> Last time, someone proposed to add `private` like `C++'s`,
We've discussed the 'private' topic very many times already.
C++'s private necessitate the 'friend' keyword, which comes
with it's own problems.
Besides, D has zero problems with its private implementation
in the sense that there has been zero bugs related to it
being that way. Given the number of individuals who bring
this topic up over and over up is so few that I don't think
there is a common problem.
Do you have actual bugs related to this? "Wanting" the
inclusion of a feature is sufficient.
In contrast, I use D every day and love its relaxed attitude
towards private.
> and then it
> was the same,they are always unwilling to add facilities
useful
That is not correct. The truth is, nobody is jumping to
implementations just because some people think they are
useful. There are always valid reasons for including a
feature or not.
Ali
You mentioned previously that D implements various things in
unprincipled ways.
I guess, if one wants to use D, one has to be comfortable with
this.
But using a relaxed attitude towards the implementation of
such a common and important abstraction, that in turn allows
me to so easily shoot myself in the foot, is not really an
attractive feature .. to me ;-)
btw. When a newbie to D raises ideas, suggestions, etc... and
you counter them with (in essence) 'we don't need that in D,
but go write a dip if you think we do' attitude, is a real
turn off.
Most of the time, when people use "private", they are actually
shooting their users which can't even extend their class. I
rarely see code which people use "protected" instead and I find
that pretty lacking. One thing is hiding memory allocation
details on your class, other thing is hiding a property which
could and should be controlled when extended in a class.
To be fair I'm more often than not against private variables.
Most of the time it only caused me headaches because there was
a lot of unimplemented features and I could not simply fork the
project. This is not only in D. I got that in Java, Haxe, C#.
Thankfully those languages has ways to simply ignore the
private attribute, which can't be done in D.
Anyway, I'm not against static classes and I don't think they
would bring any inherent problems, they should not cause
regression and they should be easy to implement as the compiler
already has the tools for it
Glad to hear someone say they're not 'against' something ;-)
btw. The Swift programming language is superior to D with regards
to the notion of type privacy.
That is, Swift has fileprivate (which provides **the exact** same
flexibility of D's private), but Swift (unlike D), *does* allow
the programmer to choose to have aspects of their type private to
that type. To something similar to Swift private in D, the
programmer is **required** to have that type - and nothing else,
in a module. That then places an important design decision in the
hands of the langauge, rather than the programmer.
It's unlikely this aspect of Swift is in any way 'unprincipled',
but more likely, a very well thought out decision to give
programmers control of their design.
So uising a term someone else mentioned in this thread, the
programmer is 'free' to make their own choices around type
privacy in Swift, but not in D :-(
