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
