> Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive > example to illustrate that this proposal could actually improve > something...even if there are cases which cannot be repelled with the simple > advice "just don't subclass", this would only be a basis to start talking > about the actual pros and cons.
> Leonardo Pessoa responded: ...an app which will have object representations > of Files and Folders (both come from a common class called Entry). You [can] > extend from File and Entry freely but...it is important you don't subclass > any type of Folder. Without this proposal I would have to create workarounds > to prevent you from doing that while still allowing me to subclass while > playing a lot of finals everywhere. And so far I would have to allow you to > subclass Folder itself (at least) but you would complain (and possibly file a > bug report to me) because it would not be working properly because your > classes would not benefit from the workaround. In this case, if I could > subclass internally but prevent you from doing it, you could complain I'm not > allowing you to do whatever you want but you wouldn't complain my code > doesn't work properly (it does, you just won't know it). To me, this scenario seems like an example of why the proposal should be rejected. Correct me if I’m wrong, but your (Leonardo’s) narrative suggests that the subclassability of File and Entry is incidental. If the intent was actively to allow people to provide their own implementations of filesystem objects, you would presumably have taken whatever steps were necessary to make Folder subclassable as well. This scenario ends up defining a perfectly commonplace mix of classes. Some of them behave reasonably when subclassed and some don’t. The question is, should Swift — as a matter of default policy and community style — actively push you to seal ALL of these classes? No, it shouldn’t. You’d be removing the possibility of functionality that’s potentially useful to some clients, without gaining much in return. A “sealed” keyword or equivalent seems plausible, but it shouldn’t be the default. Even an affirmative “sealed" feels prone to abuse, however. In this case, for example, I would imagine there would be considerable temptation to mark all objects (Entry, File, Folder, etc.) as sealed, just because Folder needs it. API designers (and clients!) dislike unexplained asymmetry. Garth
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
