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@swift.org>
Sent: 10/07/2016 05:47 PM
To: "swift-evolution" <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
