On Friday, 11 May 2018 at 10:43:19 UTC, rikki cattermole wrote:
> Classes are expensive, not everybody wants to pay for what it gives in all situations.

Mmm...that claim is so broad is to be meaningless.

Good memory allocation algorithms, intelligent optimising compilers/runtimes, prudent use of class inheritance and other features, etc..etc.... all this can change performance one way or the other.

Programs that do not use classes can (very easily) become poor peforming too.

Anyway... nice way for you to sidetrack my argument ;-)
(which is about correcting, the incorrect implementation of class enscapsulation in D - so I can start using it).

On 11/05/2018 11:25 PM, KingJoffrey wrote:
> On Friday, 11 May 2018 at 10:43:19 UTC, rikki cattermole wrote:
>> Classes are expensive, not everybody wants to pay for what it gives in all situations.
> 
> Mmm...that claim is so broad is to be meaningless.
> 
> Good memory allocation algorithms, intelligent optimising compilers/runtimes, prudent use of class inheritance and other features, etc..etc.... all this can change performance one way or the other.
> 
> Programs that do not use classes can (very easily) become poor peforming too.
> 
> Anyway... nice way for you to sidetrack my argument ;-)
> (which is about correcting, the incorrect implementation of class enscapsulation in D - so I can start using it).

Well then, since you don't like how it is now, lets see the DIP.

On Friday, 11 May 2018 at 11:37:17 UTC, rikki cattermole wrote:
>
> Well then, since you don't like how it is now, lets see the DIP.

it deserves to treated as a 'bug', not an DIP.

On 12/05/2018 12:23 AM, KingJoffrey wrote:
> On Friday, 11 May 2018 at 11:37:17 UTC, rikki cattermole wrote:
>>
>> Well then, since you don't like how it is now, lets see the DIP.
> 
> it deserves to treated as a 'bug', not an DIP.

It works as designed. There is no bug here.

Make a DIP please.

Might I suggest going back to the sealed classes topic? I don't think the discussion in this thread should go in the direction about the sense of using classes, proper encapsulation and the memory related stuff.

On Friday, 11 May 2018 at 12:59:21 UTC, Piotr Mitana wrote:
> Might I suggest going back to the sealed classes topic? I don't think the discussion in this thread should go in the direction about the sense of using classes, proper encapsulation and the memory related stuff.

Actually, it is completely on topic. (although I understand that many on this forum are very eager to shut down any discussion about fixing class encapsulation in D, for some reason).

i.e, to be more specific.. so you can understand...my reply to 'do I want sealed classes in D', is simply no. What I want first, is a class that can properly encapsulate itself.

Until that occurs, any talk about expanding the class concept with yet more attributes (that probably won't mean what you think they mean), like sealed, is just irrelevant and pushes the problem of broken encapsulation even further down peoples code paths.

private is not private at all in D, and because of this, classes are fundamentally broken in D (by design apparently).

Now.. I really do have better ways to spend my time. I've made my point. Nobody who uses D seems to think in a similar way, apparently, so I leave it at that.

On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:
> [snip]
>
> Actually, it is completely on topic. (although I understand that many on this forum are very eager to shut down any discussion about fixing class encapsulation in D, for some reason).
>
> i.e, to be more specific.. so you can understand...my reply to 'do I want sealed classes in D', is simply no. What I want first, is a class that can properly encapsulate itself.
>
> Until that occurs, any talk about expanding the class concept with yet more attributes (that probably won't mean what you think they mean), like sealed, is just irrelevant and pushes the problem of broken encapsulation even further down peoples code paths.
>
> private is not private at all in D, and because of this, classes are fundamentally broken in D (by design apparently).
>
> Now.. I really do have better ways to spend my time. I've made my point. Nobody who uses D seems to think in a similar way, apparently, so I leave it at that.

I think the last point in the conversation was "write a DIP". Nothing is going to change unless someone does that.

Personally, I don't agree with the idiomatic D doesn't use classes much argument. If that's the case, then they should be removed from the language. The language supports OOP/inheritance and if this is something that makes that experience better, then let it stand on its merits. But a new keyword will not get added without a DIP.

On Friday, May 11, 2018 15:02:08 jmh530 via Digitalmars-d wrote:
> I think the last point in the conversation was "write a DIP". Nothing is going to change unless someone does that.
>
> Personally, I don't agree with the idiomatic D doesn't use classes much argument. If that's the case, then they should be removed from the language. The language supports OOP/inheritance and if this is something that makes that experience better, then let it stand on its merits. But a new keyword will not get added without a DIP.

D supports OOP, and OOP should work. It's just that if most code isn't using classes much, then adding features specific to OOP isn't as valuable and may not be worth the extra complication it adds to the language.

However, if a solid enough use case is presented in a DIP, then it could be added. The fact that a feature relates to classes definitely doesn't make it a guarantee that it's not worth having. It just reduces its overall value and makes it so that it's likely going to need to present a stronger case than a feature that helps a lot more code might. Ultimately though, it comes down to how good the arguments and use cases presented in the DIP are and how Walter and Andrei feel about it. And even if a feature were highly likely to be accepted if a DIP were written, if a DIP isn't written, then it isn't happening.

So, if someone feels strongly about a potential feature (whatever that feature may be), and they want it in the language, they need to put in the time and effort to write a solid DIP. Discussing it may help improve the DIP, but ultimately, it's the DIP and how Andrei and Walter react to it that matters.

- Jonathan M Davis

On Friday, 11 May 2018 at 15:02:08 UTC, jmh530 wrote:
> But a new keyword will not get added without a DIP.

Yes, I know it definitely needs a DIP - I've opened a discussion in order to gather community members' opinions on sealed and decide whether to write this DIP at all and possibly track down some concept issues at the very beginning.

On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:

> private is not private at all in D, and because of this, classes are fundamentally broken in D (by design apparently).
>
> Now.. I really do have better ways to spend my time. I've made my point. Nobody who uses D seems to think in a similar way, apparently, so I leave it at that.

Classes are *not* broken in D. The module is the lowest level of encapsulation and provides exactly what encapsulation is supposed to provide -- the ability to hide the implementation from the outside world so that it may be changed without breaking the API. Being able to access private class members in the same module does not break encapsulation. If you make a change to the class that breaks something in the module, you have access to the module to fix what is broken. It's no different than what happens when you break code in the class itself, e.g this:

```
module m;

class Foo {
   private int x;
}

void manipFoo(Foo f) { f.x += 1; }
```

is no different than this:

```
module m;

class Foo {
   private int x;

   void manip() { x += 1; }
}
```

In both case, a change to the name or type of x can break the local functions and, in both cases, the person changing x has access to the local functions to fix the breakage. I don't see how putting the function outside or inside the class declaration makes any difference.