I personally agree with most of your assessments. It's why I pushed so hard for "allow subclassing my default" in the first discussion of this point.
The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as non-final. I also can seal a class which has previously been open to subclassing. Consider: someone builds against my framework and I do nothing, and they subclass my classes. Then later I come through and mark the classes as "Sealed". What should we do with those classes that are subclassing my classes? Nothing. I can't. I permitted access and now I'm beholden to that access level. On the other hand, opening up access levels gradually has no such issues. Users of my class can't subclass, and then they can. They just have another tool in the bag now. If you want a default, it should be one you can reverse later. Your default should not be the most restrictive. Whilst I agree with most of your points, this core concept seems to trump them to my mind. - Rod > On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > Please stop saying that this proposal will bring more consideration to the > design of libraries. It isn’t true. I haven’t even seen an argument for why > it would be true, it is just taken for granted that it is true. > > As I mentioned in another post, this is structurally very different from > things like ‘if-let’ and optionals. Optionals force the user to consider > their decision in the context it is being used (i.e. as you use the > optional/value). This proposal, however, does the opposite. The effect of > your actions appear in the context of a completely different user. It is > like sitting in a room, flipping a light switch wondering “I wonder what this > does?”… meanwhile the people downstairs are wondering why their lights keep > turning off and on”. > > You can try to test for this, but by definition library authors can only test > for scenarios that they have thought of. I have often found people surprise > me with their use-cases. Relying on the diligence of other programmers is > what leads to things like: "You always need to remember to test for zero > before using a pointer". Literally the opposite of optionals! It sounds > good, but at the end of the day, people are human and they WILL make > mistakes. Best to either catch those mistakes in the context where they > happen or to mitigate the effect of it. This proposal basically forces you > to feel the full effect of other people's mistakes (thinking that it will > discourage them from making them in the first place). > > Your only real mechanism for feedback is when users of your library complain > to you that something that they need isn’t subclass-able. This is the point > where most framework authors will actually learn that this feature/default > exists. Users of a framework will learn of it slightly earlier, when they > find they need to subclass something, and it just isn’t possible. > > > I would much prefer adding a ‘sealed’ keyword which library authors could use > to annotate things which they do not want subclassed outside of the module. > Or preferably, as others have suggested, allow augmentation of ‘final’ with > ‘public(final)' or ‘internal(final)’. > > The only case where I would support ‘sealed’ by default is if there are 3 > levels: open, sealed, final. Final would allow 'public(final)' and > 'internal(final)’ to allow private subclassing inside the file/module. > Sealed would be the same, except it would allow the user to subclass by > explicitly acknowledging the risk using ‘unsafe’: “unsafe class > MySubclass:SealedSuper“ and “unsafe override func”. Final would not allow > the override. > > That is the case where ‘sealed’ makes sense as a default… > > Thanks, > Jon > > P.S. The current proposal will only cause massive problems down the line, > IMHO. We will find an escape hatch is needed, but we will have made > optimizations based on assumptions of finality which prevent us from easily > adding one. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
