> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution > <swift-evolution@swift.org> a écrit : > > 2016/07/15 16:37、Riley Testut via swift-evolution <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>> のメッセージ: > >> FWIW, I'm still against this proposal, but since it will be accepted >> regardless, here are my thoughts: >> >> • Open keyword is significantly better. >> • Members should be *open* by default, and final should be opt-in. If you're >> opening up a class for subclassing, my gut says you should allow the client >> to do as they wish. > If you have a class that was not open yet, just making it open wouldn't > expose any members: it would then just be subclassable. > > If the act of making the class open doesn't implicitly make overriding > possible, well all you can do then is add methods, and that can be done with > extensions anyways, so it's not as useful and makes the public open class {} > pattern just by itself not so useful imho... 😬 > > Also, the keyword 'open' itself may imply 'hey I'm open, please do what you > want with my public members', whereas 'subclassable' is more specific in > intention... (but that's just me, so n=1 and all that) > > TLDR; +1 to the above: simpler is better and defaulting to overridable for > public members on an open class is simpler... invariants can be protected by > the 'final' keyword. > > If we were to default to non-overridable, a more consistent 'open' on the > method is preferred over overridable for me... open class, open method... > much better imho...
Do we really need an open keyword ? As already said, if open does nothing more than allowing the class to be subclassed, why not simply make the class subclassable if it contains at least one overridable member ? In case we require an open keyword, what would happen if someone mark a member overridable, but does not make the class open ? Will the compiler emit an error, or make the class implicitly « open » ?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
