On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
>
> Ultimately, if newcomers don't want to be tripped up on stuff like this, their best bet is probably to read books like Andrei's "The D Programming Language" and Ali's "Programming in D."
>

"The unit of object encapsulation in D is the class." - page 175, The D Programming Language, 2010, Andrei Alexandrescu.

What it really should have included, locally, within that same section, is the implications of this 'encapsulation' with regards to how 'facebook like friendship' is a core design component of the D module.

i.e, on the next line, Andrei could have continued..

"However, if your class is contained within a module, then this encapsulation barrier kinda breaks down, because everything in the module becomes a friend of that class, whether you like it or not. You have no say in the matter. If you don't like it, fine, but that's how D does things, so just be careful what you put in a module".

On Wednesday, 16 May 2018 at 02:15:45 UTC, KingJoffrey wrote:
>
> "The unit of object encapsulation in D is the class." - page 175, The D Programming Language, 2010, Andrei Alexandrescu.
>
> What it really should have included, locally, within that same section, is the implications of this 'encapsulation' with regards to how 'facebook like friendship' is a core design component of the D module.
>
> i.e, on the next line, Andrei could have continued..
>
> "However, if your class is contained within a module, then this encapsulation barrier kinda breaks down, because everything in the module becomes a friend of that class, whether you like it or not. You have no say in the matter. If you don't like it, fine, but that's how D does things, so just be careful what you put in a module".

Although, to be fair to Andrei, once you get to page 200 (25 pages after the above comment about class encapsulation), you do, finally, get some clarification:

"In all contexts, private has the same power: it restricts symbol access to the current module (file). This behavior is unlike that in other languages, which limit access to private symbols to the current class only. ...  If class-level protection is needed, simply put the class in its own file."

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
>
> Though if someone expects to be able to just jump into any language and use it without reading up on how it works, they're just shooting themselves in the foot. And surprisingly often, that seems to be how many folks operate.
>

And that comment is a little unfair don't you think?

The best clarification I can find, regarding how D treat's private, is from this tiny little sentence (from which, I assume, the programmer is now meant to understand it's full implications):

"Symbols with private visibility can only be accessed from within the same module"

https://dlang.org/spec/attribute.html#visibility_attributes

On Tuesday, 15 May 2018 at 19:56:58 UTC, Patrick Schluter wrote:
> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
>> On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:
>>> On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:
>>>> On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:
>>>>> [...]
>>>>
>>>> If 'getting a module to respect the enscapsulation boundaries the programmer puts in place would change the language so 'fundamentally', then the language 'already' presents big problems for large complex application development.
>>>>
>>> Evidence for this claim please.
>>
>> - Object independence
>> - Do not violate encapsulation
>> - Respect the interface
>>
>> All large software projects are done in (or moving toward) languages that respect these idioms.
>>
>> Those that don't, are the ones we typically have problems with.
>>
>> Isn't that evidence enough?
>
> That's not evidence, that's pure opinion. There's not a shred of data in that list.

Actually, that is the history of the evolution of programming large, complex systems, that have to be to correct, safe, and amenable to change.

What other approach would work?

On Wednesday, May 16, 2018 02:39:22 KingJoffrey via Digitalmars-d wrote:
> On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
> > Though if someone expects to be able to just jump into any language and use it without reading up on how it works, they're just shooting themselves in the foot. And surprisingly often, that seems to be how many folks operate.
>
> And that comment is a little unfair don't you think?

Is it? How many programmers just start trying to program in D without actually reading much of anything about it? We not only have the spec but multiple books on the language - some of which are available for free - and yet plenty of programmers (regardless of the language) seem to think that they can just start programming in a language and only look up stuff when they run into a problem and yet expect to have that work well without running into serious problems. Anyone taking that approach is just begging for trouble. Obviously, not everyone does that, but a suprisingly large number of programmers seem to. We try to help such folks when they do ask questions, but plenty of questions that get asked clearly show that the person asking the question has not studied the language much at all.

> The best clarification I can find, regarding how D treat's private, is from this tiny little sentence (from which, I assume, the programmer is now meant to understand it's full implications):
>
> "Symbols with private visibility can only be accessed from within the same module"
>
> https://dlang.org/spec/attribute.html#visibility_attributes

It specifies what private does quite accurately. If you want something that's trying to point out how you might misunderstand the spec or what problems you might run into, you'll need to read something like Ali's book. The spec is telling you how the language works, not trying to tell you how you might misunderstand it or what misakes you might make. And the information it gives there is quite accurate and complete. Honestly, I would have thought that knowing that private is private to the module would be plenty to understand what that then means for structs or classes, but everyone thinks differently and absorbs or misses different pieces of information. But ultimately, anyone who doesn't understand something is free to ask in places like D.Learn or stackoverflow.

- Jonathan M Davis

On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
>
> It specifies what private does quite accurately. If you want something that's trying to point out how you might misunderstand the spec or what problems you might run into, you'll need to read something like Ali's book. The spec is telling you how the language works, not trying to tell you how you might misunderstand it or what misakes you might make. And the information it gives there is quite accurate and complete. Honestly, I would have thought that knowing that private is private to the module would be plenty to understand what that then means for structs or classes, but everyone thinks differently and absorbs or misses different pieces of information. But ultimately, anyone who doesn't understand something is free to ask in places like D.Learn or stackoverflow.
>
> - Jonathan M Davis

To suggest that "Symbols with private visibility can only be accessed from within the same module" - is all you need to know (if you're lucky to find the needle in the haystack), is kinda elitist.

People expect norms to be the norm. That's entirely reasonable.

If I see a STOP sign while I'm driving, I expect it means STOP, not 'STOP..if.."

If I see private, I expect it means private, not 'private..if'.

The language reference could, and should do better.

On Wednesday, 16 May 2018 at 03:36:39 UTC, KingJoffrey wrote:
> On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
>>
>> [...]
>> - Jonathan M Davis
>
> To suggest that "Symbols with private visibility can only be accessed from within the same module" - is all you need to know (if you're lucky to find the needle in the haystack), is kinda elitist.

One is expected to know the tool they are using. There is nothing elitist about that.

> People expect norms to be the norm. That's entirely reasonable.
>
> If I see a STOP sign while I'm driving, I expect it means STOP, not 'STOP..if.."
>
> If I see private, I expect it means private, not 'private..if'.

There is no if. You know what the stop sign means because someone told you what it means. private means it is only available to the module. It is entirely the fault of the user for not reading the docs.

> The language reference could, and should do better.

Its actively being improved, but in this case it was more than adequate. The spec was pretty clear that private applies to modules.

On Wednesday, May 16, 2018 03:36:39 KingJoffrey via Digitalmars-d wrote:
> On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
> > It specifies what private does quite accurately. If you want something that's trying to point out how you might misunderstand the spec or what problems you might run into, you'll need to read something like Ali's book. The spec is telling you how the language works, not trying to tell you how you might misunderstand it or what misakes you might make. And the information it gives there is quite accurate and complete. Honestly, I would have thought that knowing that private is private to the module would be plenty to understand what that then means for structs or classes, but everyone thinks differently and absorbs or misses different pieces of information. But ultimately, anyone who doesn't understand something is free to ask in places like D.Learn or stackoverflow.
> >
> > - Jonathan M Davis
>
> To suggest that "Symbols with private visibility can only be accessed from within the same module" - is all you need to know (if you're lucky to find the needle in the haystack), is kinda elitist.
>
> People expect norms to be the norm. That's entirely reasonable.
>
> If I see a STOP sign while I'm driving, I expect it means STOP, not 'STOP..if.."
>
> If I see private, I expect it means private, not 'private..if'.

I don't see why it would be elitist to expect folks to read the spec and assume that it means what it says. It's always a risk that someone is going to assume that a language that they're learning works the same way as a language that they know even if it doesn't, but anyone learning a new language needs to take into account the fact that every language works differently, and you need to read up on how the language you're learning actually works if you want to avoid misunderstanding stuff. private is far from the only feature in D that doesn't work quite like it does in other languages.

> The language reference could, and should do better.

I think that really what you want is something that's geared more towards teaching the language. The ways that the language spec needs to be improved really revolve around making it a proper spec, which means making it far more precise, not making it more amenable to folks reading it in order to learn the language. But unfortunately, what we have right now is kind of in the middle. It's not precise enough to really be a proper spec, and it's generally terse enough that it's harder to use it as a learning resource (though it usually has the necessary information in it).

- Jonathan M Davis

On Wednesday, 16 May 2018 at 03:52:43 UTC, Uknown wrote:
>
> One is expected to know the tool they are using. There is nothing elitist about that.
>

That is a pathetic, and yet another elitist view.

If programmers never programmed until they 'understood the tool', there would not be 20+ million programmers in the world.

How many C++ programmers understand C++ (let alone have read the spec).

The same can be asked for pretty much any other language.

Learning is still a gradual process - except for elitists it seems, who expect you to know everything up front.

> There is no if. You know what the stop sign means because someone told you what it means. private means it is only available to the module. It is entirely the fault of the user for not reading the docs.
>

Another elitist view.

>
> Its actively being improved, but in this case it was more than adequate. The spec was pretty clear that private applies to modules.

I disagree.

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
> The ways that the language spec needs to be improved really revolve around making it a proper spec, which means making it far more precise, not making it more amenable to folks reading it in order to learn the language.

I love it. I'll add that to my list of 'D forum qoutes'.