On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>
> `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.

'private' is "meant" to be part of the implementation of 'the class'.

Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).

This is an abomination!

A class should have the capacity to protect its attributes/methods - even from the module.

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>>
>> `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.
>
> 'private' is "meant" to be part of the implementation of 'the class'.
>
> Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).
>
> This is an abomination!
>
> A class should have the capacity to protect its attributes/methods - even from the module.

Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwslxni@forum.dlang.org

On Friday, 11 May 2018 at 05:10:08 UTC, Uknown wrote:
> On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
>> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>> Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).
>>
>> This is an abomination!
>>
>> A class should have the capacity to protect its attributes/methods - even from the module.
>
> Let's not start this discussion again
> https://forum.dlang.org/post/tksnoqntxtpgqbwslxni@forum.dlang.org

If an encapsulation problem is highlighted again and again, may be it's time to acknowledge at least that there is a problem.

On Friday, 11 May 2018 at 05:10:08 UTC, Uknown wrote:
> On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
>> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>>>
>>> `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.
>>
>> 'private' is "meant" to be part of the implementation of 'the class'.
>>
>> Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).
>>
>> This is an abomination!
>>
>> A class should have the capacity to protect its attributes/methods - even from the module.
>
> Let's not start this discussion again
> https://forum.dlang.org/post/tksnoqntxtpgqbwslxni@forum.dlang.org

My point is, that adding sealed or anything else to classes, is a waste of time, cause a class is D, is not really a class at all.

A class in D, is some unprinciple pseudo-class, that cannot truly encapsulate itself any longer.

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
> Also, classes are pretty inconvenient because they are hard to use without the GC.
>
I find it surprising that a language that had Garbage Collection as one of its' key features, now has that feature looked at as an inconvenience. Was it a design error, or did the wrong class of users latch onto the language?

On 11/05/2018 8:00 PM, Tony wrote:
> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>> Also, classes are pretty inconvenient because they are hard to use without the GC.
>>
> I find it surprising that a language that had Garbage Collection as one of its' key features, now has that feature looked at as an inconvenience. Was it a design error, or did the wrong class of users latch onto the language?

GC is the right memory management strategy for a lot of use cases.
But there is many more where it isn't the right one.

D however is naturally more useful and hence successful in the second set of cases (see Weka.IO and Sociomantic as examples).

And no, you can use classes without the GC pretty easily. Its just that structs are even easier still and we do love counting cpu cycles.

On Thursday, 10 May 2018 at 14:48:23 UTC, rikki cattermole wrote:
> module foo;
> 
> class A { }
> 
> final class B : A {    }
> 
> in one module, he wants to be able to create a new
> 
> final class C : B {    }
> 
> and keep class B as final so that no one else can extend it in another module.

Not entirely. Let's use code to explain. We have:

    module pack.foo;

    sealed class A {}
    class B : A {}  // Legal
    final class C : A {}  // Legal

    sealed(pack) class D {}
    class E : D {}

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

    module pack.bar;

    class F : A {}  // Illegal, A is sealed
    class B1 : B {}  // Legal, B is not sealed - A is
    class C1 : C {}  // Illegal of course, as C is final

    class D1 : D {}  // OK, D is package-sealed
    class E1 : E {}  // OK, E is neither sealed nor final

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

    module anotherpack.baz;

    class G : A {}  // Illegal, A is sealed
    class B2 : B {}  // Legal, B is not sealed
    class C2 : C {}  // Illegal, C is final

    class D2 : D {}  // Illegal, D is package-sealed for pack
    class E2 : E {}  // Legal, E is neither sealed nor final

In general: sealed means a special case of neither private, protected nor final and it probably could not be achieved with a combination of these two.

Sealed does not mean private, as access to the class is not restricted in any way. It is also not transitive - class extending a sealed class can be extended freely unless they are sealed as well or final. Given those classes:

    sealed class Pet {}
    class Cat : Pet {}
    class Dog : Pet {}

we can implement a different types of Cats and Dogs - but creating a Ferret or Parrot is illegal. So it may be used to limit one level of inheritance, but retain the freedom to extend the few defined types. Making the base class private would not be OK, as we don't want to restrict the access to that class.

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>>
>> `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.
>
> 'private' is "meant" to be part of the implementation of 'the class'.
>
> Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).
>
> This is an abomination!
>
> A class should have the capacity to protect its attributes/methods - even from the module.

You can use D private with Java-like "only for members functions" meaning by putting it alone in it's module, if you want.

On Friday, 11 May 2018 at 09:47:39 UTC, Dukc wrote:
> On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
>> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>>>
>>> `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.
>>
>> 'private' is "meant" to be part of the implementation of 'the class'.
>>
>> Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction).
>>
>> This is an abomination!
>>
>> A class should have the capacity to protect its attributes/methods - even from the module.
>
> You can use D private with Java-like "only for members functions" meaning by putting it alone in it's module, if you want.

Yes. I do know this. But that is essentially.. a hack.

A 'private' declaration should be part of the implementation of the class, not the class+module. Some say this is just a philosphical difference - I say it's a key design issue for structured programming.

A 'class' in D, should really be called a 'companion' (of the module), rather than a 'class', cause 'class' cannot truly implement it's own abstraction, but instead has its abstraction absorbed into the higher abstraction of the module.

So now, in D, to understand the class, you must also understand the module.

This is a backwards step in language design, in my opinion - for various reasons which are easy to examine further.

When I can contain the class abstraction within the class, then I will begin to take D more seriously.

Perhaps this is why some say 'idiomatic' D does not really use classes (cause they haven't been implemented correctly anyway, so why bother using them).

On 11/05/2018 10:32 PM, KingJoffrey wrote:
> When I can contain the class abstraction within the class, then I will begin to take D more seriously.
> 
> Perhaps this is why some say 'idiomatic' D does not really use classes (cause they haven't been implemented correctly anyway, so why bother using them).

We have vastly different views on the subject.
Classes are expensive, not everybody wants to pay for what it gives in all situations.