On 7/12/25 5:35 PM, Jonathan M Davis wrote:
> On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali
Çehreli via Digitalmars-d-learn wrote:
>> On 7/11/25 11:36 PM, Bienlein wrote:
>>
>> > Unhappily class MessageBox is private and therefore cannot be
reused.
>>
>> Ah! :) That's one more data point against 'private', that little feature
>> that helps with nothing. I don't know what language invented it but I
>> wouldn't be surprised if it came to D from C++.
>>
>> The only thing 'private' achieves is this: You don't want your users to
>> be disappointed when they go out of their way to use features that they
>> are advised not to use, and those features behave differently in the
>> future. Really? That never happens. Well, if it indeed happened ever,
>> the user went out of their way to be surprised, didn't they?
>>
>> Meanwhile, engineers like you suffer because of 'private'. I pick
>> engineering over 'private' any day.
>
> Whereas I think that using private makes perfect sense when you want
> something to be an implementation detail.
Anything can be a part of the implementtion without being behind the
'private' keyword. For example, I can name those details with an
underscore and there: they are obviously not part of the public API.
> Exposing it means that you have to
> deal with someone using it, you have to design its API for public
use, and
> you can't change it without breaking code.
That's my main problem with this weird feature of programming languages.
There are different categories of useful stuff in the languages: arrays,
loops, unittest, etc.
And then there is 'private'. Some programmer writes an implementation
detail 20 years ago:
2005: Awesome code written by Alice without 'private'
2020: Bob found it useful to use some implementation detail
2025: The original code is changed by Charles
2025.01: Bob's code broke
2025.02: Today's Alice doesn't care; Alice of 20 years ago doesn't exist
anyway
Is that something a programming language should handle? Please compare
it with other useful features of programming languages. They
collectively make an engineering tool. 'private' does not contribute.
Access specifiers have nothing to do with the behavior of the program.
And I claim their improvement on code maintenance is a fallacy. I
followed that gospel without any question for decades. Now I see that it
was wasted neural bandwidth.
Aside: I have similar feelings for 'const' because as soon as it
interferes with what I'm trying to do, I replace it with 'auto'. Hm?
What happened there? What was the value of 'const' then? Say, I made a
variable 'const' yesterday but I want to change its value e.g. inside a
loop today. Do you think I respect my decision from yesterday and create
a separate variable to mutate? No: I replace 'const' with 'auto' and get
things done. Seen from this angle, 'const' is another little friend of
'private' that cannot.
More aside: I "grew up" in C++ circles and did follow many gospels
there. It took me a while to see the light on religious guidelines.
A stab at C++: "costexpr everything". Ha ha! My translation: "We
continue to fail, so you should follow hundreds of guidelines to write
correct programs."
> If anything, making something
> public when it doesn't need to be makes it harder to maintain and
refactor
> that code.
Sure, 'public' when used explicitly is an implication. What if I do not
use any access specifier and name some variables with an underscore.
Anything that is accessible is *not* part of an API. The API comes with
documentation and examples. Any person who strays from the API can do
whatever they want.
> As far as public libraries go, any time that any symbol is
> public, someone is going to use it, and you're stuck with its design.
Not at all. I am responsible only for the "API" part of my library: A
couple of structs and a couple of functions. I can change the rest as
freely as I want.
> And when the code is open source, if someone wants to use it, they can
> always just copy it into their own code and do whatever they want with it
> without creating any additional burden for the maintainers of the library
> that the code was taken from.
Although done even by me, that's not advisable because that person would
be living with undiscovered bugs in their copy.
> But when you make a symbol public in a
> library which is publicly available, you're essentially creating a
contract
> with your users and limiting the changes that you can make to the those
> symbols.
That's a fallacy. I can change any non-API feature. And what if it broke
a person's code? Who is this fictional person anyway? Do you see how all
of this stands on hypothesis?
> So, there's a real cost to making a symbol public, and I'm 100% in
> the camp that symbols should not be public if they don't need to be.
So, we are in agreement: If access specifiers did not exist, nobody
would make any symbol 'public.' ;)
> private symbols are
> implementation details which can be changed as necessary so long as those
> changes don't break the functionality provided by the public symbols. So,
> from the standpoint of code maintenance, there can be real value in
keeping
> symbols private.
The different view point I have is that how such a feature is not
necessary and is outside of the useful feature set a programming
language provides. I can't imagine that Alice in the scenario above
really wants to protect an unknown user in the future. A protection from
a slight possibility that what that used found useful may change in the
future. This is absolutely the wrong kind of focus on an engineering
tool. It smells a lot like what C++ programmers tell each other to do
religiously. And I strongly think gospel-style craftspersonship of
programming is behind these mostly-unquestioned "features'.
> - Jonathan M Davis
Ali
