On 05/15/2018 04:05 PM, Jonathan M Davis wrote:
> On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote:
>> On 5/15/2018 10:17 AM, aliak wrote:
>>> On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
>>>> The way you use the word "leak" make is sounds that this is
>>>> unintentional, while in reality it is intentional by design. That why
>>>> reading the specification is important!
>>>>
>>>> Alexander
>>>
>>> Ya I guess you be right - but a leak is what it is to people who expect
>>> private to mean private. Which is not a small number of people ;)
>>>
>>> And while I agree reading a spec is important. Language specs are not
>>> known for being trivial to go through and it's not really something you
>>> read but more of something you refer to, and that also probably for more
>>> advanced developers. This is not something you can expect newcomers or
>>> even intermediate level devs to go through. And the less you need to
>>> refer to a spec the better (i.e. more intuitive) a language is.
>>
>> I concur with that.  When I first started learning D (coming from a C#
>> background), I figured that I already knew all of the OOP stuff and
>> didn't dig too deeply into it, figuring that it worked pretty close to
>> the same as C#.  It did catch me off guard when I first realized how it
>> really worked in D.  But the work around (putting it in its own module),
>> seemed pretty trivial and is what I typically do in C# anyways, so it
>> didn't bother me too much.
> 
> I think that if there's an actual problem here, it's the fact that how
> private works in D is surprising to folks coming from languages like C++,
> C#, or Java. IMHO, D's approach works extremely well, but if you don't
> understand what it is, you risk problems, just like with any other feature
> that you don't understand properly. And to better deal with that, we
> probably need more in the way of documentation geared towards teaching
> newbies. The "spec" is pretty poor in that it's not precise enough to be a
> spec, meaning that it doesn't really do its job in that respect, but it's
> also not really written with the idea that it's teaching someone, so it
> doesn't do a great job teaching the language either. There's a lot of great
> information there, but it's ultimately not all that accessible for many
> folks.
> 
> 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.
> 
> 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."
> 
> https://wiki.dlang.org/Books
> 
> - Jonathan M Davis
> 

To clarify myself a little bit, the main points that I was agreeing with were:

1. I think there are significant number of people coming from other languages that are going to get tripped up by D's module level encapsulation, mainly because it happened to me.

2. The spec is hard to use as a training resource, because I tried to use it and didn't have a good experience with it.

I ended up reading all of the free material that I could find (including the Programming in D book).

I also wasn't trying say anything about D's encapsulation being right or wrong, just that it tripped me up initially, and that now that I know how it works, it isn't a big deal for me.

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
> 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

Also, having a C++ like spec, written by the elite, for the elite, and then everyone else has to wait until some kind person explains the spec, is really not a great model.

It's equivalent to the elitist view of trickle down economics - which is not working in my country.

On Wednesday, 16 May 2018 at 05:43:58 UTC, KingJoffrey wrote:
>
> Also, having a C++ like spec, written by the elite, for the elite, and then everyone else has to wait until some kind person explains the spec, is really not a great model.
>
> It's equivalent to the elitist view of trickle down economics - which is not working in my country.

oh, and btw, even the elite don't truly understand the tool. they, they like all people, understand bit and pieces of this and that, some bits more than others, some less than others.

Please find me the number of C++ programmers who understand C++.

https://www.youtube.com/watch?v=YAP_xTsapW0

KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
> The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....

Well, that's not entirely true.
Visibility in Rust is similar to D.
There's no one true language semantics that holds for all languages. That's
the point of having different languages.

On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:
> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>> The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....
>
> Well, that's not entirely true.
> Visibility in Rust is similar to D.
> There's no one true language semantics that holds for all languages. That's
> the point of having different languages.

actually, private is default in Rust.

public is default in D.

also, in Rust, private is private within the module, *and* its descendants.

I don't believe that is the case in D (someone correct me if I'm wrong)

KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
> actually, private is default in Rust.
> 
> public is default in D.
> 
> also, in Rust, private is private within the module, *and* its descendants.
> 
> I don't believe that is the case in D (someone correct me if I'm wrong)

The point is, that the module is the abstraction boundary.

Tobias Müller <troplin@bluewin.ch> wrote:
> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>> actually, private is default in Rust.
>> 
>> public is default in D.
>> 
>> also, in Rust, private is private within the module, *and* its descendants.
>> 
>> I don't believe that is the case in D (someone correct me if I'm wrong)
> 
> The point is, that the module is the abstraction boundary.
> 
> 

s/abstraction/encapsulation/

On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:
> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>> The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....
>
> Well, that's not entirely true.
> Visibility in Rust is similar to D.
> There's no one true language semantics that holds for all languages. That's
> the point of having different languages.

Also, my point was not that different languages should not be different.

My point was to be aware of the potential for misunderstandings of what 'most' people would expect to hold true.

And that point comes back to the very reason I interjected into this discussion (some time back) - because someone though it might be a great idea to introduce a sealed class - but how many people would end up thinking that the keyword 'sealed' means "sealed as in Scala, not as in C#".

My point holds up, because 'most' (not all, sure) programmers use languages where terminology means the same thing. And I think D needs to be conscious of this when using well known terminologies/concepts, because what I like most about D, is that I can bring my existing knowledge from other mainstream langauges, and start using D productively, very quickly. I cannot say the same for Rust and Go. I almost DO have to go and read the spec before I start using it.

On Wednesday, 16 May 2018 at 06:11:13 UTC, Tobias Müller wrote:
> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>> actually, private is default in Rust.
>> 
>> public is default in D.
>> 
>> also, in Rust, private is private within the module, *and* its descendants.
>> 
>> I don't believe that is the case in D (someone correct me if I'm wrong)
>
> The point is, that the module is the abstraction boundary.

oh, sorry, I thought your point was that "Visibility in Rust is similar to D."

On Wednesday, 16 May 2018 at 06:05:31 UTC, KingJoffrey wrote:
> On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:
>> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>>> The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....
>>
>> Well, that's not entirely true.
>> Visibility in Rust is similar to D.
>> There's no one true language semantics that holds for all languages. That's
>> the point of having different languages.
>
> actually, private is default in Rust.
>
> public is default in D.
>
> also, in Rust, private is private within the module, *and* its descendants.
>
> I don't believe that is the case in D (someone correct me if I'm wrong)

`public` by default is again not a problem. Just apply `private` as necessary. Also, if you want the rust style `private`, D offers `package`, which means private to the modules contained by a package.