Sealed classes - would you want them in D?

[Piotr Mitana]

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.