I don't love this idea, I'm not very fond of the final keyword, either; I've always believed annotations (or attributes in PHP these days) are a better of way of indicating you, as an author of a class, did not write it with inheritability in mind or intended than restricting language features through syntactic constructs.
The RFC says "when you have a class in your code base that shares some implementation detail between 2 or more other objects, your only protection against others making use of this class is to add `@internal` annotation, which doesn't offer any runtime guarantee that no one is extending this object", to which I ask - why do you need this guarantee? What does it qualitatively add? If I make a judgement that I want to extend your class or implement your interface, I can just delete the sealed keyword from your code and carry on. So it doesn't actually offer any guarantee at all that I'm not extending the type. The best it can achieve is to indicate your intentions, which I believe can be adequately done today through an attribute, no addition to the language needed. On Sat, Apr 24, 2021 at 9:01 PM Christian Schneider <cschn...@cschneid.com> wrote: > Am 24.04.2021 um 21:51 schrieb Marco Pivetta <ocram...@gmail.com>: > > On Sat, Apr 24, 2021, 21:44 Olle Härstedt <olleharst...@gmail.com > <mailto:olleharst...@gmail.com>> wrote: > > > >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati <azj...@void.tn>: > >>>> Doesn't this violate the principle: It should be possible to add new > >>>> features without touching old code? > >>> > >>> This depends on which syntax is picked, both `for` and attribute syntax > >> will > >>> be completely BC. > >> > >> I'm not talking about BC, but the maintainability of the new feature > >> itself. For the shape example, you'd need to edit the original file > >> for each new shape you add, which is detrimental for maintainability > >> and scalability. So what's a good use-case? > > I'm with Olle here: This sounds like an anti-pattern to me. > The example could not be worse: Why should I not be allowed to add a > hexagon shape? > > > The main use-case of sealed types is being able to declare total > functions > > around them. > > Could you elaborate on what's the real-world use-case for your main > use-case? > This sounds like another case of a feature based in (math) theory which > leads to artificially locked down code. > > - Chris > >
