On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:
>
> A slippery slope fallacy isn't helping your case. Write a DIP if it bothers you so much, as it changes the languages fundamentally.
>
>
> Alexander

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.

Little old me ranting about it in some DIP isn't going to do much.

D is great for small, quick stuff though - I'll give it that. I enjoy using D for small stuff.

But C++/Java/C# users all expect private to mean private, as it should, and will, like me, get a nasty shock when they come over to D, and discover it my mistake, as I did.

It was only through debugging my code, did I realise I had disprespected the boundaries I set up, because the module let me do it, and the compiler thought that's what I must have wanted. I simply could not have made that mistake in any of the other langauges I use.

Clearly others take a different perspective on this issue, that's fine, I just don't get the case they're trying to make. It hasn't made any sense to me thus far.

Removing respect for encapsulation boundaries, in order to avoiding the need for using C++ like 'friend', sounds a bit dodgy to me. No matter how much I think about it, I'd rather have those boundaries and be forced to use friends.

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:
> On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:
>>
>> A slippery slope fallacy isn't helping your case. Write a DIP if it bothers you so much, as it changes the languages fundamentally.
>>
>>
>> Alexander
>
> 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.


> But C++/Java/C# users all expect private to mean private,

We expect that users C++/Java/C# to know that D is not C++/Java/C# and to read the specification.

Again write a DIP if this bothers you. You are not going to make any language changes by ranting about it on the forums.

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:
>>>
>>> A slippery slope fallacy isn't helping your case. Write a DIP if it bothers you so much, as it changes the languages fundamentally.
>>>
>>>
>>> Alexander
>>
>> 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?

D modules provide uncontrolled violation of encapsulation (i.e can bypass the interface), and completely undermine these established idioms.

D modules, will let anyone (within that module) access your wallet and take whatever they want.

http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf

>
>> But C++/Java/C# users all expect private to mean private,
>
> We expect that users C++/Java/C# to know that D is not C++/Java/C# and to read the specification.
>
> Again write a DIP if this bothers you. You are not going to make any language changes by ranting about it on the forums.

yeah.. I get it.. don't discuss anything, don't explore ideas or why others might think differently, just go off and write a DIP. That's why DIP's are so often poorly written and not worth the time of those that have to look at them.

I think such talk is just a way to shut down the converation, to be honest.

Based on this discussion so far, what I've gauged, is that spending the effort to write a dip, would be pointless (at least at this stage).

If D ever takes off (and I'm not sure it will, precisely because of the way it disregards those idioms I mentioned), then more pressure will come on D to change - and perhaps then sufficient support for a DIP would be there. But I honestly don't see how it can take off, unless if first respects those idioms.

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:
>>>>
>>>> A slippery slope fallacy isn't helping your case. Write a DIP if it bothers you so much, as it changes the languages fundamentally.
>>>>
>>>>
>>>> Alexander
>>>
>>> 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?

I'm seeing the opposite, more and more large applications adopting Python as much as possible and replacing big chunks of the C++ core and leaving only those C++ chunks where performance is all that really matters.

Encapsulation boundaries are completely arbitrary and where D choses to draw the line works very well in practice.

Bye,
Norm

On Tuesday, 15 May 2018 at 03:32:22 UTC, Norm wrote:
>
> I'm seeing the opposite, more and more large applications adopting Python as much as possible and replacing big chunks of the C++ core and leaving only those C++ chunks where performance is all that really matters.
>
> Encapsulation boundaries are completely arbitrary and where D choses to draw the line works very well in practice.
>
> Bye,
> Norm

"Encapsulation boundaries are completely arbitrary.."

I love it.

We have so much to look forward to, as more and more languages, and more and more quality software projects, embrace that 1950's idiom.

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

>
> - Object independence
> - Do not violate encapsulation
> - Respect the interface

This is what I don't get from your position. What is encapsulation? Here's what Wikipedia says [1]:

"Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object."

This has been my understanding of encapsulation since I first learned of it years ago. How is this broken in D? Only if you insist on viewing it in a strictly theoretical sense. As a matter of practical reality, it is not broken.

If you have access to the internals of the class, you also have access to the rest of the module. No client of the class outside of the module has any access to the implementation. I showed you an example earlier of how silly it would be to force the rest of the module to use some sort of "module private" interface.

The class in D *is* encapsulated. The interface *is* respected. I'm not sure what you mean by object independence.


[1] https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

On Tuesday, May 15, 2018 04:22:30 Mike Parker via Digitalmars-d wrote:
> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> > - Object independence
> > - Do not violate encapsulation
> > - Respect the interface
>
> This is what I don't get from your position. What is encapsulation? Here's what Wikipedia says [1]:
>
> "Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object."
>
> This has been my understanding of encapsulation since I first learned of it years ago. How is this broken in D? Only if you insist on viewing it in a strictly theoretical sense. As a matter of practical reality, it is not broken.
>
> If you have access to the internals of the class, you also have access to the rest of the module. No client of the class outside of the module has any access to the implementation. I showed you an example earlier of how silly it would be to force the rest of the module to use some sort of "module private" interface.
>
> The class in D *is* encapsulated. The interface *is* respected. I'm not sure what you mean by object independence.
>
>
> [1]
> https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

If you really insist on the viewpoint that class encapsulation means that nothing outside of that class can access any of its private members, then what D does definitely breaks encapsulation. But having friends in C++ already provides a way to break that. And having access levels like protected and package break it. Ultimately, a good language provides ways to encapsulate data and control access to the internals of a data type, but there are a variety of ways that that can be achieved, and I don't think that I've ever used a language that strictly enforces that nothing can access the internals of a class. It's just that each language provides different ways for stuff outside the class to access the class' internals.

D happens to have gone with a very liberal approach to encapsulation by essentially making everything inside a module friends of each other. It doesn't break the concept of encapsulation any more than C++'s friend or Java's package attribute do. It's just a much more liberal default, and if you're really insistent that nothing outside of a class has access to the stuff inside a class, then D's choice is likely to be seem terrible. So, in that sense, I can see where he's coming from, but ultimately, I think that it's a very narrow viewpoint about what encapsulation means, and for most of us, experience has shown that D's choice works extremely well in practice.

Either way, as long as you understand how D works with private, you have basically the same level of control as what you get with C++ and friend. It's just that if you _really_ don't want anything else to be a friend, you're forced to stick it in another module. So, ultimately, I think that it's mostly a theoretical debate. Pretty much the worst that happens is you accidentally use a member variable directly instead of using a property function to access it, and that's rarely a big deal. Often, it's even desirable.

Regardless, I think that it's quite clear that we're not going to convince KingJoffrey of anything, and it's unlikely that he's going to convince us - though honestly, with that username, I have to wonder if he's complaining about this issue to just screw around with us for fun. But even if he's completely serious, I think that it's clear that at best we're going to agree to disagree.

- Jonathan M Davis

On Tuesday, 15 May 2018 at 04:22:30 UTC, Mike Parker wrote:
> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
>
>>
>> - Object independence
>> - Do not violate encapsulation
>> - Respect the interface
>
> This is what I don't get from your position. What is encapsulation? Here's what Wikipedia says [1]:
>
> "Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object."
>
> This has been my understanding of encapsulation since I first learned of it years ago. How is this broken in D? Only if you insist on viewing it in a strictly theoretical sense. As a matter of practical reality, it is not broken.
>
> If you have access to the internals of the class, you also have access to the rest of the module. No client of the class outside of the module has any access to the implementation. I showed you an example earlier of how silly it would be to force the rest of the module to use some sort of "module private" interface.
>
> The class in D *is* encapsulated. The interface *is* respected. I'm not sure what you mean by object independence.
>
>
> [1] https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

Yes, it's a vague word which can be interpreted different ways.

I primarily mean the more abstract notion of 'boundaries' and 'interfaces'.

The concept is well presented in this keynote at ACCU 2018:

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

E.g. passing from one room to another, via a door. The door presents the boundary, and the interface through which you access each room. You cannot go star trek style (yet) and just beam from one room to the other.

'Beam me up scotty' is just for the movies (as far as I know ;-)

Also, if there is no boundary between the orange room and the blue room, how would I get from the orange room to the blue room - or vica versa?

The only reality our brains can perceive, is the reality made of from boundaries and interfaces. We cannot hold all of reality in our head. We have to break things down into little self-contained chunks, and then understand how the chunks connect together.

It becomes particularly important when trying to understand complexity (of any kind).

943294432432812  // grr!

943_294_432_432_812 // nice

the underscore represent the boundary.
the information between boundaries is now encapsulated (because of that boundary)

Now, back to D...

in this example code below, the D module does not respect the boundary of the object.

That is, the module can beam into the object without going through the interface.

I struggle to understand why the module is allowed to do this - I really cannot get my head around any valid reason for it - I'm just getting told, 'that's how D does it' -or - 'it doesn't really bother us'.

If I cannot control the interface, and have that respected by the module, then this allows the kind of bugs that actually lead me to working out that private is not really private at all.

And that bug would not have happened in C++/Java/C# - or, as far as I know, Rust and Go. They would have all respected the boundary.

D has chosen to allow the module to disrespect the interface. Why?

(and don't tell me it does - cause the code below clearly demonstrates that it does not)

=======
module test;

void foo()
{
    Person p = new Person("King Joffrey");

    // this completely bypasses my interface
    // (i.e. the boundary that I set up between the class and the module)
    p._name = "New King";

}

class Person
{
    private string _name;

    public void setName(string name)
    {
        this._name = name;
    }

    public this(string name)
    {
        _name = name;
    }

}

================================

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
>
> If you really insist on the viewpoint that class encapsulation means that nothing outside of that class can access any of its private members, then what D does definitely breaks encapsulation. But having friends in C++ already provides a way to break that.

No. That is not true.

friend is explicately part of the declared interface.

D on the otherhand, tells you who your friends are.

Your interface doesn't have a say in it anymore.

When your declared interface is moot, your enscapsulation is also moot.


> Regardless, I think that it's quite clear that we're not going to convince KingJoffrey of anything, and it's unlikely that he's going to convince us - though honestly, with that username, I have to wonder if he's complaining about this issue to just screw around with us for fun. But even if he's completely serious, I think that it's clear that at best we're going to agree to disagree.
>
> - Jonathan M Davis

I prefer to think of it as a discussion. Even though I'm right ;-)

But in any case, i feel I've presented some worthwhile arguements.

The only arguments I've got so far from the other point of view, is that's how D does it. If you don't like it, go wrute a DIP.

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
> Pretty much the worst that happens is you accidentally use a member variable directly instead of using a property function to access it, and that's rarely a big deal. Often, it's even desirable.

I'll keep that argument for the status quo, and will be sure to put it in the DIP.