Just a though, but why sealed classes have to be completely unsubclassable ?
Wouldn't it be possible to allow the user to subclass sealed class, but deny overriding of any public member. I see a use case where a user want to extends an existing model by adding new properties and new methods to an object but can’t use composition because doing that will prevent to pass that object to the framework that expect the base object. That would let user override existing class to extends them, but should not cause any side effect in the way the class should behave, and so would not affects preconditions and postconditions, and should not prevent optimization in whole module compilation, as the methods of the base class are considered final outside of the module. Of course, it will introduce some fragility in the library, as adding new methods may conflict with user subclass methods, but no more than what would append if the user write extension to add new methods to the model. > Le 11 juil. 2016 à 05:38, Jordan Rose via swift-evolution > <[email protected]> a écrit : > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md> > ] > > (This is my second response to this proposal. The previous message shared a > use case where public-but-non-subclassable made things work out much better > with required initializers. This one has a bit more ideology in it.) > > As many people have said already, this proposal is quite beneficial to > library designers attempting to reason about their code, not just now but in > the future as well. The model laid out in the Library Evolution document > <http://jrose-apple.github.io/swift-library-evolution/> (often referred to as > “resilience”) supports Swift libraries that want to preserve a stable binary > and source interface. > > In the Swift 2 model (and what’s currently described in that document), a > public class must be final or non-final at the time it is published. It’s > clearly not safe to add ‘final' in a later version of the library, because a > client might already have a subclass; it’s also not safe to remove ‘final’ > because existing clients may have been compiled assuming there are no > subclasses. > > (Of course, we can remove this optimization, and make ‘final’ a semantic > contract only. I’m deliberately avoiding most discussion of performance, but > in this parenthetical I’ll note that Swift makes it possible to write code > that is slower than Objective-C. This is considered acceptable because the > compiler can often optimize it for a particular call site. For those who want > more information about the current implementation of some of Swift’s > features, I suggest watching the “Understanding Swift Performance > <https://developer.apple.com/videos/play/wwdc2016/416/>” talk from this > year’s WWDC.) > > With this proposal, a public class can be non-publicly-subclassable or > publicly-subclassable. Once a class is publicly-subclassable (“open”), you > can’t go back, of course. But a class that’s not initially open could become > open in a future release of the library. All existing clients would already > be equipped to deal with this, because there might be subclasses inside the > library. On the other hand, the class can also be marked ‘final’, if the > library author later realizes there will never be any subclasses and that > both client authors and the compiler should know this. > > One point that’s not covered in this proposal is whether making a class > ‘open’ applies retroactively, i.e. if MagicLib 1.2 is the first version that > makes the Magician class ‘open’, can clients deploy back to MagicLib 1.0 and > expect their subclasses to work? My inclination is to say no; if it’s > possible for a non-open method to be overridden in the future, a library > author has to write their library as if it will be overridden now, and > there’s no point in making it non-open in the first place. That would make > ‘open’ a “versioned attribute > <http://jrose-apple.github.io/swift-library-evolution/#publishing-versioned-api>” > in the terminology of Library Evolution, whatever the syntax ends up being. > > --- > > Okay, so why is this important? > > It all comes down to reasoning about your program’s behavior. When you use a > class, you’re relying on the documented behavior of that class. More > concretely, the methods on the class have preconditions > (“performSegue(withIdentifier:sender:) should not be called on a view > controller that didn’t come from a storyboard”) and postconditions (“after > calling loadViewIfNeeded(), the view controller’s view will be loaded”). When > you call a method, you’re responsible for satisfying its preconditions so it > can deliver on the postconditions. > > I used UIViewController as an example, but it applies just as much to your > own methods. When you call a method in your own module—maybe written by you, > maybe by a coworker, maybe by an open source contributor—you’re expecting > some particular behavior and output given the inputs and the current state of > the program. That is, you just need to satisfy its preconditions so it can > deliver on the postconditions. If it’s a method in your module, though, you > might not have taken the trouble to formalize the preconditions and > postconditions, since you can just go look at the implementation. Even if > your expectations are violated, you’ll probably notice, because the conflict > of understanding is within your own module. > > Public overriding changes all this. While an overridable method may have > particular preconditions and postconditions, it’s possible that the overrider > will get that wrong, which means the library author can no longer reason > about the behavior of their program. If they do a poor job documenting the > preconditions and postconditions, the client and the library will almost > certainly disagree about the expected behavior of a particular method, and > the program won’t work correctly. > > "Doesn’t a library author have to figure out the preconditions and > postconditions for a method anyway when making it public?" Well, not to the > same extent. It’s perfectly acceptable for a library author to document > stronger preconditions and weaker postconditions than are strictly necessary. > (Maybe 'performSegue(withIdentifier:sender:)’ has a mode that can work > without storyboards, but UIKit isn’t promising that it will work.) When a > library author lets people override their method, though, they're promising > that the method will never be called with a weaker precondition than > documented, and that nothing within their library will expect a stronger > postcondition than documented. > > (By the way, the way to look at overriding a method is the inverse of calling > a method: you need to deliver on the postconditions, and you can assume the > caller has satisfied the preconditions. If your understanding of those > preconditions and postconditions is wrong, your program won’t work correctly, > just like when you’re calling a method.) > > This all goes double when a library author wants to release a new version of > their library with different behavior. In order to make sure existing callers > don’t break, they have to make sure all of the library’s documented > preconditions are no stronger and postconditions are no weaker for public > API. In order to make sure existing subclassers don’t break, they have to > make sure all of the library’s documented preconditions are no weaker and > postconditions are no stronger for overridable API. > > (For a very concrete example of this, say you’re calling a method with the > type '(Int?) -> Int’, and you’re passing nil. The new version of the library > can’t decide to make the parameter non-optional or the return value optional, > because that would break your code. Similarly, if you’re overriding a method > with the type ‘(Int) -> Int?’, and returning nil, the new version of the > library can’t decide to make the parameter optional or the return value > non-optional, because that would break your code.) > > So, "non-publicly-subclassable" is a way to ease the burden on a library > author. They should be thinking about preconditions and postconditions in > their program anyway, but not having to worry about all the things a client > might do for a method that shouldn’t be overridden means they can actually > reason about the behavior—and thus the correctness—of their own program, both > now and for future releases. > > --- > > I agree with several people on this thread that > non-publicly-subclassable-by-default is the same idea as internal-by-default: > it means that you have to explicitly decide to support a capability before > clients can start relying on it, and you are very unlikely to do so by > accident. The default is “safe” in that a library author can change their > mind without breaking existing clients. > > I agree with John that even today, the entry points that happen to be public > in the types that happen to be public classes are unlikely to be good entry > points for fixing bugs in someone else's library. Disallowing overriding > these particular entry points when a client already can't override internal > methods, methods on structs, methods that use internal types, or top-level > functions doesn’t really seem like a loss to me. > > Library design is important. Controlling the public interface of a library > allows for better reasoning about the behavior of code, better security (i.e. > better protection of user data), and better maintainability. And whether > something can be overridden is part of that interface. > > Thanks again to Javier and John for putting this proposal together. > Jordan > > P.S. There’s also an argument to be made for public-but-not-conformable > protocols, i.e. protocols that can be used in generics and as values outside > of a module, but cannot be conformed to. This is important for many of the > same reasons as it is for classes, and we’ve gotten a few requests for it. > (While you can get a similar effect using an enum, that’s a little less > natural for code reuse via protocol extensions.) > > P.P.S. For those who will argue against “better security”, you’re correct: > this doesn’t prevent an attack, and I don’t have much expertise in this area. > However, I have talked to developers distributing binary frameworks (despite > our warnings that it isn’t supported) who have asked us for various features > to keep it from being easy. > _______________________________________________ > 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
