On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
>
> Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision.

yeah, I probably agree that it's a good decision, when the module is the boundary.
(aka so-called 'principled' violation of encapsulation)

what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module.

D wants me to completely trust the module, no matter what.

That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)

On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote:

>
> That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)

Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other?

On Tuesday, 13 March 2018 at 09:52:06 UTC, Mike Parker wrote:
> On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote:
>
>>
>> That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)
>
> Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other?

The scenario you mentioned is fine, as long as I don't want to protect any of my class members from free functions within the module. When I do decide that something in my class really does need protection, I have to move the class outside of the module.

This concept is new to me. I have to keep thinking about it. To lose control at the level of class encapsulation, and surrender it completely to the module, no matter what..well..I'm a little unsure about it.

I'd be more comfortable with being able to have your scenario and mine 'both work'.

At what point, does 'principled' violation of encapsulation, just become a violation of encapsulation?

On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
> package myPackage;
>
> public class Main {
>
>     public static void main(String[] args)
>     {
>         System.out.println("Hello World!");
>         myClass c = new myClass();
>         c.myPrivateClassMember= "wtf";
>         System.out.println(c.myPrivateClassMember);
>     }
>
>     private static class myClass
>     {
>         private String myPrivateClassMember; // private does not mean private anymore??
>     }
> }
> ´´´
> (may the forum forgive me :p )

But a class and its inner classes together, can be still be reasoned about locally.

With 'modules', the boundaries of what 'local' means, becomes more and more fuzzy, as the module gets longer and longer, and more and more complex.

In those circumstances, it becomes much harder to reason locally about the correctness of a class.

And a D module can go on..well...for ever.....

I would still prefer that classes within a module, at least have a capacity to specify access privileges to objects in the same module, rather than just trusting everything in that module, without exception.

On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
> Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision.

But, a module can contain so many 'friends'.

Q. How many 'friends' does it take, before you lose the capacity to reason about who really is a friend?

On 14/03/2018 12:19 AM, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
>> package myPackage;
>>
>> public class Main {
>>
>>     public static void main(String[] args)
>>     {
>>         System.out.println("Hello World!");
>>         myClass c = new myClass();
>>         c.myPrivateClassMember= "wtf";
>>         System.out.println(c.myPrivateClassMember);
>>     }
>>
>>     private static class myClass
>>     {
>>         private String myPrivateClassMember; // private does not mean private anymore??
>>     }
>> }
>> ´´´
>> (may the forum forgive me :p )
> 
> But a class and its inner classes together, can be still be reasoned about locally.
> 
> With 'modules', the boundaries of what 'local' means, becomes more and more fuzzy, as the module gets longer and longer, and more and more complex.
> 
> In those circumstances, it becomes much harder to reason locally about the correctness of a class.
> 
> And a D module can go on..well...for ever.....
> 
> I would still prefer that classes within a module, at least have a capacity to specify access privileges to objects in the same module, rather than just trusting everything in that module, without exception.

Ah yes.
You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation.

A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up.

My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together).

This makes each file to be very right down to the point and do nothing else.

You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either.

On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote:
>
> Ah yes.
> You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation.
>
> A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up.
>
> My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together).
>
> This makes each file to be very right down to the point and do nothing else.
>
> You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either.

Fair enough.

I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-)

I have to think more, about what a module is really trying to encapsulate.

I'm sure there is a good blog that could come out of this conversation.
(not by me though)

On 14/03/2018 1:02 AM, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote:
>>
>> Ah yes.
>> You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation.
>>
>> A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up.
>>
>> My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together).
>>
>> This makes each file to be very right down to the point and do nothing else.
>>
>> You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either.
> 
> Fair enough.
> 
> I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-)

The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality.

> I have to think more, about what a module is really trying to encapsulate.
> 
> I'm sure there is a good blog that could come out of this conversation.
> (not by me though)

While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years.

On Tuesday, 13 March 2018 at 12:10:07 UTC, rikki cattermole wrote:
> On 14/03/2018 1:02 AM, psychoticRabbit wrote:
>> On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote:
>>>
>>> Ah yes.
>>> You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation.
>>>
>>> A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up.
>>>
>>> My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together).
>>>
>>> This makes each file to be very right down to the point and do nothing else.
>>>
>>> You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either.
>> 
>> Fair enough.
>> 
>> I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-)
>
> The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality.
>
>> I have to think more, about what a module is really trying to encapsulate.
>> 
>> I'm sure there is a good blog that could come out of this conversation.
>> (not by me though)
>
> While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years.

Mmm...I think more than just 'some people' will be suprised when they come to D, and suddenly find that a private member may not be private at all.

Particulary those C++/C#/Java programmers - who represent the vast majority of programmers on the planet.

private string _Name;

(oh..in D, this might be private..or it might not be..depends on what you mean by private)

On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
> Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision.

Actually I wonder if it's the opposite of that, because now, if I have a bug in my class implementation, the code is no longer localised to the class, but to the module - this greatly increases the burden of program correctness and maintenance.

It also means the author of the class is no longer free to make changes, because all the surrounding code in the module needs to be assessed for impact - this greatly increases the burden of program correctness and maintenance.