On Monday, 29 October 2018 at 09:25:07 UTC, unprotected-entity wrote:
> On Monday, 29 October 2018 at 06:15:25 UTC, Mike Parker wrote:
>> Encapsulation inside the file is rather pointless.
>
> Say that to yourself a few times, and see if your view changes ;-)

I have, and it hasn't :-)

>
> (btw. just take a look at the length of some 'files', within Phobos - I mean, gee, I really hope the developer of those files did not share your view)

Classes can take up just as much space, presenting the same potential issue.

>
> In any case, encapsulation in a file, still exists, just not so much for classes
> - function still have it, scope braces still have it..etc..etc... but one of the most important constructs in programming, the class, does not.

I don't think I've ever heard of anyone speak of encapsulation in terms of function scopes and anonymous scopes. That's a fairly narrow definition. At any rate, I don't put variables inside a function to keep them out of the public API.

And yes, classes do have encapsulation. Private class members are hidden from the public API.

>
> It's not just that it could happen 'by accident', it's that D actively encourages this, by making 'private' (within a module), a completely useless construct.
>
> It's there by default.

Being the default isn't the same as encouraging it.

>
> Just how often does one need to access the private members of a class, within a module?

I can't speak for others, but it's a feature I use fairly often. I tend to design aggregates and free functions to the module, as a cohesive whole, rather than as separate parts. If I want separate parts, I put them in different modules and use `package` for the bits that need to stay out of the public API. Works a treat.

On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
>
> I can't speak for others, but it's a feature I use fairly often. I tend to design aggregates and free functions to the module, as a cohesive whole, rather than as separate parts. If I want separate parts, I put them in different modules and use `package` for the bits that need to stay out of the public API. Works a treat.

Well. In the end, it seems like nobody will be able to convince Walter and Andrei (and you too it seems), that there is some real practical merit, in allowing a class within a module, to have the capacity to protect its private parts.

I find that really odd. (I mean, really, really odd).

That doesn't translate to..hey ..lets change the way 'private' works within a module  ...so that we can break everyones code...

But there are realtive easy ways to give the programmer more choice over this, without 'complexity' becoming a geniune issue (that's just used by some as an excuse not to do anything).

But nobody seems willing to listen to those proposals.

Doesn't affect me. I already have great programming languages that already do what I want them to do.

I'd like to 'play' with D. But when private actually means public (inside a module), and when I the programmer have no control over this (within a module), then, my interest in D cannot be sustained.

If you have a class in a module, and you have anything else in that module, then the encapsulation of your class is immediately suspect - and anyone reviewing your code has to go looking to see exactly what you're doing - because what the class says about it interface, is irrelevant.

On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
>
> I don't think I've ever heard of anyone speak of encapsulation in terms of function scopes and anonymous scopes. That's a fairly narrow definition. At any rate, I don't put variables inside a function to keep them out of the public API.

How is that a narrow definition on encapsulation?

A function hides distracting details, and exposes a simple interface to its client.

What goes on inside, is mostly irrelevant to the client, as long as it does what it's meant to do. Typically, you can go and change how it does it, without affecting the client.

That's encapsulation..surely.

The argument is a little harder to make for an anonymous scope, I give you that, but it also can have encapsulating properties in any case.

There should never really be any need to get at the interior of a function, outside of that function? Use it's interface. That's why it's there.

I'm just making the same case for classes.

structs on the otherhand, well ... do what you want with 'em ;-)

On Mon, 29 Oct 2018 05:13:22 +0000, unprotected-entity wrote:
> I wonder if that would still be the case, if millions and millions of C++/Java/C# programmers suddenly came over to D (and discovered, likely by accident, or by some obscure bug in their code), that a class is not considered a unit of encapsulation anymore.

Java, C++, and C# all treat `private` differently, so if you're saying we should do the exact same as they do, your request is inconsistent and therefore unsatisfiable.

I think this is the third time I've pointed it out.

> I think Go and Rust have done it better, somewhat, in that they don't even have classes. So you are forced to rethink your design anyway (if you want to use those languages)

Go and Rust use `private` the same as D. Shouldn't we cater to programmers familiar with those languages by making `private` work like they expect?

> Yes, there are situations in which it might be useful, I get it. But surely not every situation?

Which is why Swift has five different protection levels (but it skipped `protected` for some reason). That's a bit more complexity than I think is warranted.

On Monday, October 29, 2018 7:52:47 AM MDT unprotected-entity via Digitalmars-d wrote:
> On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
> > I can't speak for others, but it's a feature I use fairly often. I tend to design aggregates and free functions to the module, as a cohesive whole, rather than as separate parts. If I want separate parts, I put them in different modules and use `package` for the bits that need to stay out of the public API. Works a treat.
>
> Well. In the end, it seems like nobody will be able to convince Walter and Andrei (and you too it seems), that there is some real practical merit, in allowing a class within a module, to have the capacity to protect its private parts.
>
> I find that really odd. (I mean, really, really odd).

If anything, many of us have been convinced of the opposite by actually using D. The way that D treats private is pratical and useful, and adding a way to further restrict access to member variables of classes would just be a further complication to the language with little to no pratical benefit.

If you don't like that, that's fine. I don't think that any of use like _every_ design decision made in D, but many of us do like this design decision, and plenty of folks had a negative reaction to it when they initially found out. However, experience tends to show that D's design decision here works extremely well.

- Jonathan M Davis

On Mon, 29 Oct 2018 05:13:08 +0000, unprotected-entity wrote:
> On Sunday, 28 October 2018 at 11:32:07 UTC, Mike Parker wrote:
>>
>> In D, the module is the unit of encapsulation, not the class.
> 
> Again. this is not entirely correct.
> 
> -----
> class Foo { private int i; }
> 
> void main()
> {
>   {Foo f;}
>   f.i++;
> }
> 
> ----
> 
> It's really hard to have a converstation when posts are being checked by 'someone', at 'their leisure', before (or if) they ever get posted??

There are two concepts here: scope and encapsulation. This is a demonstration of scope. A variable that is not in scope might point to data that doesn't currently exist, or there might simply be no way to refer to that data in an unambiguous way.

In your example, an optimizing compiler might have destroyed `f` and reclaimed its memory at the end of its block.

A related example shows the ambiguity as well:

---
class Foo { private int i; }
void main()
{
  {Foo f = new Foo;}
  {Foo f = new Foo;}
  f.i++;
}
---

Similarly with your function example, there's no general way to refer to variables in other functions. Your function can't know where it's called from, so it can't refer to variables higher up on the stack. Variables that are lower down on the stack have already been destroyed. Plus with recursion, you can't specify which copy of a variable you're talking about.

On Monday, 29 October 2018 at 09:15:35 UTC, unprotected-entity wrote:
> On Monday, 29 October 2018 at 08:34:39 UTC, FeepingCreature wrote:
>> Yes they do.
>> ---
>> module test;
>> import std.stdio;
>> class C { int a; }
>> void main() { writeln(a); } // Error: undefined identifier 'a'
>
> Sorry, but you are wrong.
>
> Why? Because 'a' is nothing - it does not even exist. Not anywhere.

Yes, it does exist as a symbol :
---
import std.stdio;
class C { int a; }
void main() { writeln(typeof(C.a).stringof); }
---

> To make it exist, you need to instantiate an object of C.

No, see code above. Of course you would need to instantiate C to *use* it. But you would also need to call your test function to use its variable a.

> Once it actually 'exists', you can do whatever you like with it, in the module, regardless of its access modifier. That means, quite simply, that the class is not a unit of encapsulation - within the module. Outside the module it is, but inside, it is not.

Yes, exactly. These are the official D rules.

> That is just fact. It's not something we should be arguing about - cause it's just a fact.
>
> On the otherhand, a function (unlike a class) within a module, still retains it's encapsulating properties.
>
> i.e.
> void test() {int a;};
> void main() {a++;}; // Error: undefined identifier 'a' - but this time, 'a' does exist - it's just that its correctly encapsulated in the function.

You're confusing the existence a symbol and the path to access it. While there is a way to point to the field name 'a' in class 'C' in the code above (i.e `C.a`), there is no way to point to the variable 'a' in function test. So these are not encapsulation differences. Encapsulation is about whether or not you can use a symbol that you can point to with the correct syntax in the first place.

> Just imagine if a function did not have those encapsulating properties.
>
> Now, just imagine if a class did not (well, you don't need to imagine it ;-)
>
> I'm not trying to argue here. I'm just trying to clarify a fact, that some seem unable, or unwilling, to accept.

Not clarified for me ;)
Though I agree with you that there could be a `class private` access modifier in D for your use case.

On Monday, 29 October 2018 at 13:52:47 UTC, unprotected-entity wrote:
[...]
> But nobody seems willing to listen to those proposals.
>
> Doesn't affect me. I already have great programming languages that already do what I want them to do.
>
> I'd like to 'play' with D. But when private actually means public (inside a module), and when I the programmer have no control over this (within a module), then, my interest in D cannot be sustained.
>
> If you have a class in a module, and you have anything else in that module, then the encapsulation of your class is immediately suspect - and anyone reviewing your code has to go looking to see exactly what you're doing - because what the class says about it interface, is irrelevant.

I hear you and understand you, but personally I still prefer the D spec as it is in this regard, except for the confusing aspect that you shouldn’t `alias this` a private member; but that is rather a limitation of alias, not of encapsulation.

Remember, the concept of encapsulation existed long before OO, arguably in a much stronger form. See the second half of https://forum.dlang.org/post/vjduytokawqtbvpslzpe@forum.dlang.org; as you see, you are not the first to bring this up. I can recommend the video link at the bottom of that post.

On Monday, 29 October 2018 at 15:50:56 UTC, Jonathan M Davis wrote:
>
> If anything, many of us have been convinced of the opposite by actually using D. The way that D treats private is pratical and useful, and adding a way to further restrict access to member variables of classes would just be a further complication to the language with little to no pratical benefit.
>
> If you don't like that, that's fine. I don't think that any of use like _every_ design decision made in D, but many of us do like this design decision, and plenty of folks had a negative reaction to it when they initially found out. However, experience tends to show that D's design decision here works extremely well.
>
> - Jonathan M Davis

It's not (just) that I don't like it, it's that I don't like not giving the programmer the tool to better encapsulate their code (specifically classes) *within* a module.

Well, as Walter said in a previous post, "Being able to declare a "friend" that is somewhere in some other file runs against notions of encapsulation."

My argument is not too dissimilar.

Forcing everything in a file, to be friends with each other, runs against the notions of encapsulation. Sure, put the class in its own module. But then you lose the encapsulation property and convenience, of the module. So you worse off, no matter how you look at it, in D.

The difference between the C++ way, and the D way, is that the C++ way (friends) is not really encouraged - i.e. it's mostly for corner cases - it's not meant to be how you go about architecturing your software - surely.

In D however, it's exactly how you're meant to do it - it's by design - it's reaching out and saying, this is how you should do it. D seems to be proud, that you cannot encapsulate a class, within a module, from other code also in that module. If C++/C#/Java took that view, imagine the outcry.

In any case, I don't really care so much about D, but about good design.

And given what I've seen in phobos..well... I'm still looking for the 'design'.

All I see are gigantic modules full of code...that does who knows what to each other..cause they're all friends and can do whatever they like to each other, in D.

On Monday, 29 October 2018 at 15:44:15 UTC, Neia Neutuladh wrote:
>
> Java, C++, and C# all treat `private` differently, so if you're saying we should do the exact same as they do, your request is inconsistent and therefore unsatisfiable.
>
> I think this is the third time I've pointed it out.
>

what 'point' is that.

can you 'point' it out again for me, cause I'm not clear what the 'point' of your 'point' is.

btw. It's interesting, how a discussion on this matter *always* ends up with posts using a tone similar to where you are now going.

i.e. it diverts more and more towards the personal, when people disagree with you.