Hello,

I've recently thought of sealed classes (sealed as in Scala, not as in C#) and am thinking of writing a DIP for it. I decided to start this thread first though to gather some opinions on the topic.

For those who never coded Scala and don't know sealed classes: a sealed class is a class which can be only extended in the same source file.

    sealed class MyClass {}

Translating to D, a sealed class would could only be extended in the same module. Additionally I would suggest "sealed(some.package) MyClass {}" syntax for classes that could only be extended in the particular package.

In Scala an important value of sealed classes is that compiler knows that and can aid programmer in pattern matching by detecting the missed cases. However, there is another value I see: limiting the extension of classes.

Some time ago I was working on a simple CQRS library and created an Entity class, where I wanted only a few specific subtypes for it. The library is built over a few defined entity types and user is not able to create their own types (should extend the particular subtype instead). Sealing the Entity class could enable me to define the closed set of subtypes and prevent new direct subtype creation outside the library.

Combining sealed with final library developer can create a completely closed type hierarchy.

Any thoughts on that proposal?

On 11/05/2018 1:22 AM, Piotr Mitana wrote:
> Hello,
> 
> I've recently thought of sealed classes (sealed as in Scala, not as in C#) and am thinking of writing a DIP for it. I decided to start this thread first though to gather some opinions on the topic.
> 
> For those who never coded Scala and don't know sealed classes: a sealed class is a class which can be only extended in the same source file.
> 
>      sealed class MyClass {}
> 
> Translating to D, a sealed class would could only be extended in the same module. Additionally I would suggest "sealed(some.package) MyClass {}" syntax for classes that could only be extended in the particular package.
> 
> In Scala an important value of sealed classes is that compiler knows that and can aid programmer in pattern matching by detecting the missed cases. However, there is another value I see: limiting the extension of classes.
> 
> Some time ago I was working on a simple CQRS library and created an Entity class, where I wanted only a few specific subtypes for it. The library is built over a few defined entity types and user is not able to create their own types (should extend the particular subtype instead). Sealing the Entity class could enable me to define the closed set of subtypes and prevent new direct subtype creation outside the library.
> 
> Combining sealed with final library developer can create a completely closed type hierarchy.
> 
> Any thoughts on that proposal?

Adding a keyword like sealed isn't desirable.

I'm trying to find fault of the concept, but it definitely is tough.

You basically want protected, but only for specific packages, otherwise final.

protected(foo, final)

On Thursday, 10 May 2018 at 13:47:16 UTC, rikki cattermole wrote:
> [snip]
>
> Adding a keyword like sealed isn't desirable.
>
> I'm trying to find fault of the concept, but it definitely is tough.
>
> You basically want protected, but only for specific packages, otherwise final.
>
> protected(foo, final)

My read was that he wants an escape hatch on final so that he can extend the type in a module and not have to worry about people in other modules extending them.

So if he has

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.

On 11/05/2018 2:43 AM, jmh530 wrote:
> On Thursday, 10 May 2018 at 13:47:16 UTC, rikki cattermole wrote:
>> [snip]
>>
>> Adding a keyword like sealed isn't desirable.
>>
>> I'm trying to find fault of the concept, but it definitely is tough.
>>
>> You basically want protected, but only for specific packages, otherwise final.
>>
>> protected(foo, final)
> 
> My read was that he wants an escape hatch on final so that he can extend the type in a module and not have to worry about people in other modules extending them.
> 
> So if he has
> 
> 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.

You're right, I just didn't put it well.

My current thinking is something along the lines of:

modifier ( !|opt IdentifierList )
modifier ( !|opt IdentifierList , modifier )

Not quite correct grammar, but close enough.

So:

final(!mypackage)

would do what Piotr wants.

On Thursday, 10 May 2018 at 13:22:20 UTC, Piotr Mitana wrote:
> Hello,
>
> I've recently thought of sealed classes (sealed as in Scala, not as in C#) and am thinking of writing a DIP for it. I decided to start this thread first though to gather some opinions on the topic.
>
> For those who never coded Scala and don't know sealed classes: a sealed class is a class which can be only extended in the same source file.
>
>     sealed class MyClass {}
>
> Translating to D, a sealed class would could only be extended in the same module. Additionally I would suggest "sealed(some.package) MyClass {}" syntax for classes that could only be extended in the particular package.
>
> In Scala an important value of sealed classes is that compiler knows that and can aid programmer in pattern matching by detecting the missed cases. However, there is another value I see: limiting the extension of classes.

[...]

> Combining sealed with final library developer can create a completely closed type hierarchy.
>
> Any thoughts on that proposal?

How about extending the behaviour of ‘private’, which means private except for this module, to ‘final’, which would then allow sub typing in the same module but not outside? It would not break any code. Are there downsides to such a change?

On 11/05/2018 3:18 AM, Bastiaan Veelo wrote:
> On Thursday, 10 May 2018 at 13:22:20 UTC, Piotr Mitana wrote:
>> Hello,
>>
>> I've recently thought of sealed classes (sealed as in Scala, not as in C#) and am thinking of writing a DIP for it. I decided to start this thread first though to gather some opinions on the topic.
>>
>> For those who never coded Scala and don't know sealed classes: a sealed class is a class which can be only extended in the same source file.
>>
>>     sealed class MyClass {}
>>
>> Translating to D, a sealed class would could only be extended in the same module. Additionally I would suggest "sealed(some.package) MyClass {}" syntax for classes that could only be extended in the particular package.
>>
>> In Scala an important value of sealed classes is that compiler knows that and can aid programmer in pattern matching by detecting the missed cases. However, there is another value I see: limiting the extension of classes.
> 
> [...]
> 
>> Combining sealed with final library developer can create a completely closed type hierarchy.
>>
>> Any thoughts on that proposal?
> 
> How about extending the behaviour of ‘private’, which means private except for this module, to ‘final’, which would then allow sub typing in the same module but not outside? It would not break any code. Are there downsides to such a change?

You can already sub type with private. What you can't do is sub type with both private and final. It should remain this way.

Let's not go changing semantics of already understood language features. Exceptions to rules are not ok, nor will they be approved.

On Thursday, 10 May 2018 at 15:18:56 UTC, Bastiaan Veelo wrote:

> How about extending the behaviour of ‘private’, which means private except for this module, to ‘final’, which would then allow sub typing in the same module but not outside? It would not break any code. Are there downsides to such a change?

This was exactly my thought. It fits right in there with Walter's reasoning, you already have access to the module's code so rather than make you jump through hoops to access, lift the restriction within the module.

To rikki's complaint, it would have the same unfortunate side affect of people complaining that they can't control the source code within the module. It wouldn't be an exception to the rule though, it would follow the rule. (I guess it depends on what rule you look at)

On Thursday, May 10, 2018 13:22:20 Piotr Mitana via Digitalmars-d wrote:
> Hello,
>
> I've recently thought of sealed classes (sealed as in Scala, not as in C#) and am thinking of writing a DIP for it. I decided to start this thread first though to gather some opinions on the topic.
>
> For those who never coded Scala and don't know sealed classes: a sealed class is a class which can be only extended in the same source file.
>
>      sealed class MyClass {}
>
> Translating to D, a sealed class would could only be extended in the same module. Additionally I would suggest "sealed(some.package) MyClass {}" syntax for classes that could only be extended in the particular package.
>
> In Scala an important value of sealed classes is that compiler knows that and can aid programmer in pattern matching by detecting the missed cases. However, there is another value I see: limiting the extension of classes.
>
> Some time ago I was working on a simple CQRS library and created an Entity class, where I wanted only a few specific subtypes for it. The library is built over a few defined entity types and user is not able to create their own types (should extend the particular subtype instead). Sealing the Entity class could enable me to define the closed set of subtypes and prevent new direct subtype creation outside the library.
>
> Combining sealed with final library developer can create a completely closed type hierarchy.
>
> Any thoughts on that proposal?

I think that the main thing is that the use case has to be strong enough to merit complicating the language further by adding such a feature, and I really don't know if the use case is really all that strong. My gut reaction is that it's catering to a very specific and rare use case and as such would not be worth adding, but I don't know. Idiomatic D tends to use classes rarely, and I can't think of any situation where what you're describing would ever have been useful to me, but that doesn't necessarily mean that some people wouldn't find it really useful, and depending on how much value it adds in such situations, it might be worth adding. Ultimately though, I think that if you want to create a DIP for something like this, you're going to need some very strong use cases where this is solving a real problem and why the current situation is lacking. If it's a significant improvement in enough situations, then you'll probably be able to get a DIP accepted, but if it's just helping in some rare cases, I'd expect it to stand a low chance of acceptance. Nothing stands out to me about the idea as being fundamentally bad though.

- Jonathan M Davis

On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis wrote:
> Idiomatic D tends to use classes rarely...

What is the basis for this assertion?

On a separate issue, 'private' should mean private! (not kinda-private).

Let's not make D classes even more of joke.

On Friday, 11 May 2018 at 03:11:48 UTC, KingJoffrey wrote:
> On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis wrote:
>> Idiomatic D tends to use classes rarely...
>
> What is the basis for this assertion?

D tends to prefer structs with UFCS member functions rather than classes, because one rarely needs the reference semantics or inheritance. Also, classes are pretty inconvenient because they are hard to use without the GC.

>
> On a separate issue, 'private' should mean private! (not kinda-private).
>
> Let's not make D classes even more of joke.

`private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions.