On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
> And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic.

yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems.

Now, if I were having this discussion with myself, your comment about spamming the topic 'might' be correct.

As it is though, everyone involved in the discussion, including yourself, is spamming the topic, in that case.

so take your own advice. create a new thread, and have a go at me there instead.

When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class.

On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
>
> Again, all you have to do is put class Person in a separate module.

This is such a nonsense solution. Why do you keep proposing it?

Is this you way to effectively sweep the problem under the carpet?

For me, a module presents the opportunity to group objects into a larger working unit.

But since D does not respect the encapsulation of objects, one has to revert to your solution, or mine (which is, if you're solution to a problem requires the use of classes, then go use a progamming language that respects the encapsulation boundary of classes).

On Sunday, 13 May 2018 at 02:36:28 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
>> And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic.
>
> yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems.

Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D.

I have a draft DIP hanging around on my hard drive relating to named function parameters, for instance. It discusses:

* The thing to be changed
* Why I think it should be changed
* Examples of how the status quo causes problems
* How I want code to work in the future
* Examples of what I want code to look like
* How other languages handle this thing

That's just due diligence for nontrivial enhancement requests. And named function parameters is a feature with probably very little opposition and moderate support.

> so take your own advice. create a new thread, and have a go at me there instead.

It should be as easy as changing the "Subject" field on the reply screen. It would have been gracious of you to do this, all things considered.

> When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class.

Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations.

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
> It should be as easy as changing the "Subject" field on the reply screen.

Apparently not. My apologies.

On 13/05/2018 5:11 PM, Neia Neutuladh wrote:
> On Sunday, 13 May 2018 at 02:36:28 UTC, KingJoffrey wrote:
>> On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
>>> And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic.
>>
>> yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems.
> 
> Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D.
> 
> I have a draft DIP hanging around on my hard drive relating to named function parameters, for instance. It discusses:
> 
> * The thing to be changed
> * Why I think it should be changed
> * Examples of how the status quo causes problems
> * How I want code to work in the future
> * Examples of what I want code to look like
> * How other languages handle this thing
> 
> That's just due diligence for nontrivial enhancement requests. And named function parameters is a feature with probably very little opposition and moderate support.
> 
>> so take your own advice. create a new thread, and have a go at me there instead.
> 
> It should be as easy as changing the "Subject" field on the reply screen. It would have been gracious of you to do this, all things considered.
> 
>> When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class.
> 
> Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations.

On that note we should chat[0].
Preferably IRC or Discord.

[0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
> Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D.
>
> Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations.

First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed.

I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched.

Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do.

Third, those who responded to my caution are the ones that should have created a separate thread, not me.

Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me.

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
>> Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D.
>>
>> Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations.
>
> First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed.
>
> I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched.
>
> Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do.
>
> Third, those who responded to my caution are the ones that should have created a separate thread, not me.
>
> Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me.

Walter is not the only person who accepts DIP and although he's the core head of D, it doesn't mean all his opinions are strictly 100% how D is going to evolve. I'm sure there are plenty of features that has been implemented that he does not entirely agree with and the same goes for others.

If you can write a DIP and have a good use case for it, other than a very rare usecase, then it would most likely be accepted, IF the language would benefit from the addition.

Writing posts about how you don't like feature X is way more useless than a DIP, because it will NOT change anything.

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
>> [...]
>
> First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed.
>
> I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched.
>
> Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do.
>
> Third, those who responded to my caution are the ones that should have created a separate thread, not me.
>
> Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me.

walter bright was not the only one who liked that idea of "only module level encapsulation". Its unfair to imply it like that.
Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore.
Thats an argument, too.

On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:

> Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore.
> Thats an argument, too.

So, when you have 1000 classes, you just create 1000 files just to "unfriend" them :)

On Sunday, May 13, 2018 17:19:26 rumbu via Digitalmars-d wrote:
> On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:
> > Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore. Thats an argument, too.
>
> So, when you have 1000 classes, you just create 1000 files just to "unfriend" them :)

Which is basically what you get in Java, though no one should be putting 1000 classes in a single module anyway. But if you want to make it so that classes can't access each other's members while still making it possible to import them together, then all you have to do is have a module which publicly imports all of those other modules which have one class each.

The only thing that you really lose with D's approach as opposed to friend is that D doesn't provide a way to mark something from another module as a friend. package at least partially solves that problem though. Really, what D went with is similar to what Java did, only it's more flexible, because it doesn't restrict what can go in a module, whereas Java only allows one public class per module and doesn't have any free functions.

Ultimately, D's solution simplifies things over what C++ did with friends while giving you basically the same level of control. It's just that if you don't want something to be able to access the private members of a class or struct, that symbol must be in a separate module. So, if you _really_ don't want anything accessing the internals of your class or struct, but you want to be able to stick stuff in the same file, then that can get annoying, because you can't do that. But public imports let you make it so that you can still import them as one even if they're not actually in the same file, and many of us have found that having the default be that other stuff in the module can access the private members to be very useful - especially with regards to testing.

I fully expect that if we added some sort of "super private" that really made it so that nothing outside a class or struct could access its members, almost no one would use it, and it wouldn't really solve much in the way of real problems, much as I'm sure that a few folks like KingJoffrey would be quite happy to have something like that.

Ultimately, there are tradeoffs between what C++ did and what D did, and neither approach is perfect, so some folks are likely to be happier with one approach over the other, but overall, what D has done has worked extremely well for D.

- Jonathan M Davis