[swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Leonardo Pessoa]

You asked me to correct you and I shall: you're wrong. Although it seems like a filesystem representation here, this is not it and the subclassability of Entry and File is intended but Folder is a special type and I cannot allow more than the base type and a few controlled subclasses due to the nature of the system. It was intended to be exactly like this and there was nothing incidental about them. IMO a well designed library is like an app with plugins: you're not entitled to do whatever you want in the app through a plugin but the app controls and dictates what it allows you to do.

You asked for an example where this feature would be needed and I've provided. As I said, a concrete and real example. But I haven't seen anyone give the slightest concrete technical reason not to approve it and please don't come saying fix bugs in a library by subclassing because that's not what subclassing is for. That is a misuse of object orientation in whichever language you're working with.

L

-----Original Message-----
From: "Garth Snyder via swift-evolution" <swift-evolution at swift.org>
Sent: ‎10/‎07/‎2016 05:47 PM
To: "swift-evolution" <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160710/64ac1cb5/attachment.html>