Intention. IMO, intention may lead to more secure systems (and libraries). By having to explicitly final everything I have to choose with parts of my class/library would be locked and have to worry and check if any public thing could be used to exploit it or make the system work in a way I did not intended to. Also, final will prevent anyone including me from extending/overriding. Defaulting to final would require from me to explicitly declare the open endpoints in my libraries, so I could explicitly open only the ones that are really intended to be used in that way by third-parties.
As an example, I'm working on a system which has an internal representation of Files and Folders using a common superclass (lets call it Entry). I would like for other developers to be able to create new entry types (not only inheriting from File) but I do not wish for them to extend from Folder or any of its subclasses (specialised folders). By using final I can prevent others from extending my Folder but I cannot extend it myself and thus need another mechanism for achieving this behaviour without bloating the Folder class with all its specialisations. This proposal would allow me to make my Folder and its subclasses publicly available/usable but would prevent others from subclassing and thus misusing them in ways I did not intend them to. The same rationale applies to methods. L On 6 July 2016 at 16:09, Goffredo Marocchi <[email protected]> wrote: > Leonardo, how is defaulting to final/sealed helping you write better > libraries than having a final keyword for what you need to close instead? > > Sent from my iPhone > > On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution > <[email protected]> wrote: > >>> The review of "SE-0117: Default classes to be non-subclassable publicly" >>> begins now and runs through July 11. The proposal is available here: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md >>> >>> * What is your evaluation of the proposal? >> >> +1. Being able to control how a class from my libraries are going to >> be used by third-parties could enable a better designed API with more >> control of how it is intended to be used. I'm just not fond of using >> the proposed keywords ('subclassable' and 'overridable') as they feel >> more like protocol or attribute names; I'd be more inclined to use the >> alternative 'public open' instead, or 'public(open)' as a second >> option. >> >>> * Is the problem being addressed significant enough to warrant a >>> change to Swift? >> >> I'd say it is significant to every language. >> >>> * Does this proposal fit well with the feel and direction of Swift? >> >> Yes. >> >>> * If you have used other languages or libraries with a similar >>> feature, how do you feel that this proposal compares to those? >> >> C# uses the keyword 'virtual' to explicitly mark methods that can be >> overriden (not considered in the alternatives but I'm not a big fan of >> it). >> >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >> >> I've took (a small) part on the thread discussing this proposal but >> followed it closely >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
