Scope modules DIP rough messy draft.

[Stanislav Blinov]

On Monday, 29 October 2018 at 15:50:33 UTC, 12345swordy wrote:
> On Monday, 29 October 2018 at 15:00:07 UTC, Stanislav Blinov 
> wrote:
>
>> So? You, the programmer, are breaking encapsulation here by 
>> accessing 'private' member.
> There is no encapsulation break, as it located in the same 
> module. The encapsulation that you speak of is human enforced.

Again, so?..
If I saw such code in C++, I'd known that it either won't 
compile, or I'd need to check if I'm in a friend code.
If I saw such code in D, my first thought would be that the 
author did that intentionally. Because *that's what D's 
'private'* is intended for.

This is quite common pattern in D:

--- list.d

struct List(T) {
     private struct Node { /* ... */ }
     private Node* head;
}

auto makeList(R)(R range) {
     import std.range;
     alias T = ElementType!R;
     alias Node = List!T.Node; // oh no, that'd break 
"encapsulation" in C++
     Node* head;
     foreach_reverse (e; range) {
         auto n = new Node(e);
         n.next = head;
         head = n;
     }
     return List!T(head);
}

--- main.d

void main() {
     auto list = [ 1, 2, 3, 4 ].makeList;
     /* ... */
}

And this doesn't just apply to lists. It becomes *very* easy to 
make complex implementations without putting in made-up 
roadblocks for yourself, or jumping through hoops to "white-list" 
friends. That is what D's 'private' for. For everything else, 
there are packages. Now, if that's not enough for you, then you 
need to show, quite clearly, *why* that is.

>> That'd be interesting to see. Why didn't you put those 
>> supposed limitations in there to begin with? I.e. what's the 
>> purpose of this "messy draft"?
> To get feedback. Which allows me to spot things that need 
> revisiting or need better explaining. This isn't the final 
> draft. Not by a long shot.

Then why are you arguing? Wouldn't it be more productive to 
analyze the feedback and update the document as you see fit? So 
far you didn't present any practical use case for your proposal, 
other than some arguable "good practice", people are saying as 
much.

>> Global variables aren't accessing anything. You (the 
>> programmer) are, by assigning values to them.
> That counter point doesn't make any sense. You act like that I 
> am arguing that they are intelligent or something.

No, you're arguing that having globals somehow breaks 
"encapsulation" of *other* data. It doesn't, not unless the 
programmer says so. Copying a *value* from a private member to 
another variable isn't breaking any encapsulation at all. You 
literally do that all the time when implementing your beloved 
getters.

>> That's not an issue with encapsulation at all. That's a 
>> lifetime issue.
> Not my point. The point is that the compiler won't complain 
> that you are getting the local variable in the function from 
> outside the function, irregardless that you set it to private 
> or not and will compile just as fine.

The compiler does complain for cases when it should, as I've 
shown in the example that you cut out. You're not getting 
anything from outside the function, you pass it over from within.

>>> Nested classes/functions are not encapsulated. The module 
>>> itself is the unit of encapsulation.
>>
>> You're confusing encapsulation and scopes now:
> *shrugs*
>  The other user treat them as one as the same.

And?..