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

[let var go]

Leonardo's example makes the case for why Swift should adopt a 'sealed'
keyword that can be used to make public classes non-subclassable outside
the module where they are defined, but not for why this should be the
default.

Others have made these points before, but these are the two biggest reasons
I can see against making public classes non-subclassable by default:

1. It is the opposite of nearly every other OOP language's behavior and the
opposite of what anyone will expect who is coming to Swift after doing any
OOP programming anywhere else. While I believe that Swift should be free to
buck the trends of other languages where there are significant advantages,
changing something this fundamental will introduce a new learning curve for
even experienced programmers. The advantages better be significant,
otherwise you are introducing a frustrating quirk into the language without
any great benefit in exchange. But the advantages of default
non-subclassability are marginal at best. Whatever advantage there is can
be achieved by making it opt-in using a 'sealed' keywrod, instead of by
making it the default.

2. The motivation seems to be that it will force better API design. On
average, I can't believe that it will. Assume that there are two kinds of
developers: Those that make careful decisions about their API design and
those that don't. The ones that make careful decisions about their API
design will continue to do so - I don't see any significant improvement to
their code by making non-subclassability the default. The developers who
don't make careful design decisions will just go with the default - in this
case they will just leave the default in place, and their public classes
will not be subclassable. That doesn't improve anything, it just makes
sloppy, poorly written code harder to fix in the off-chance that you are
stuck working with it. In other words, quality will not improve, but
productivity will suffer, because it will be harder to develop workarounds
for the problems that will inevitably appear in even the best-designed APIs.

3. It is a bad interpretation of the stated goal that Swift should help
developers produce "safe code." Some folks seem to believe that this means
that the language should protect people from themselves. If I am using your
API in my code and I screw it up by subclassing something that I shouldn't
have, that is somehow a language defect. It is not a language defect - it
is me being an idiot. Don't spend a lot of time trying to make a language
idiot-proof - idiots are geniuses and you will never outsmart them.
Personally, when I read that Swift helps produce "safe code", what that
means primarily is that it has a type system that helps reveal the vast
majority of bugs that would otherwise go unnoticed until runtime. In other
words, safety is related to discovering hidden flaws in the program. (Type
safety isn't the only feature that helps with this, but it is perhaps the
main one.) But this whole issue of default non-subclassability doesn't fall
into that category of "safety" at all. It doesn't help a programmer produce
safer code. The same hidden flaws will persist whether non-subclassability
is the default or not. The difference is that those same hidden flaws will
be more difficult to deal with after the fact.

To sum it up, +1 for introducing a 'sealed' keyword, but -1 for making it
the default behavior for public classes.

On Sun, Jul 10, 2016 at 12:18 PM Leonardo Pessoa via swift-evolution <
swift-evolution at swift.org> wrote:

> Should I assume then you want so much this proposal to be dropped you
> didn't even mind to look for the example so you wouldn't have to admit this
> proposal is needed? Fine, here is the whole of that example.
>
> I'm currently working on an app which will have object representations of
> Files and Folders (both come from a common class called Entry). You as a
> developer for this system will be entitled to extend from File and Entry
> freely but you can only work with Folders and its subclasses (specialised
> folders) but to this system 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).
>
> There may be several more examples but this is one I'm facing right now,
> so I can assure you it is a true example. IMO libraries are to be written
> with intention in mind and I don't think it is right to use a library
> written to compose a PDF file to send an email (even if you're sending the
> PDF file attached, the right way to do it is by composition not
> subclassing).
>
> Additionally, someone mentioned and I went in to check about a
> recommendation for Java to intentionally document and enable classes to be
> subclasses explicitly otherwise forbid it at all and that recommendation
> seems to come from Oracle itself. I believe Oracle would do it to Java if
> it had great interest in it without consulting anyone's opinion.
>
> About the addition to the proposal to enable force unsealing, I'm
> completely opposed as it is just like not having any of this protection at
> all (why putting a lock on the door to your house if the key is under the
> mat?)
>
> Swift doesn't have to follow on the footsteps of any language but what is
> best for the intention the language was created for. If sealed by default
> goes in that direction, then we should have it not looking back. The same
> goes if we decide this is not taking the language in its intended
> direction. If I'm not wrong at least one member of the core team already
> mentioned in this thread this is completely aligned with the intention of
> the language, so I think we should give it a go and stop trying to
> have/keep control of everything we touch.
>
> L
> ------------------------------
> From: Tino Heth via swift-evolution <swift-evolution at swift.org>
> Sent: ‎10/‎07/‎2016 01:55 PM
> To: swift-evolution <swift-evolution at swift.org>
> Cc: Jean-Daniel Dupas <mailing at xenonium.com>
> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to
> benon-subclassable publicly
>
> Two days ago, I challenged the supporters of this proposal to show a singe
> persuasive example to illustrate that this proposal could actually improve
> something.
> I got a single reply — which did not contain an example, but just the
> claim that there is one…
> Imho that alone should be enough to cancel the whole thing, because 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.
>
> So for me, the promised benefits are less likely than the existence of
> Bigfoot:
> I guess there are at least several hundred people who swore they have seen
> him, and there are even some blurry photos ;-)
>
> Of course, it is impossible to come up with an unquestionable argument for
> the change — and it's also impossible to prove the opposite, because the
> whole debate makes as much sense as arguing wether raisins are tasteful or
> terrible; it's nothing but personal preference, and the only thing we can
> hope for is that the bias of those who will decide this proposal isn't at
> odds with the needs of the majority.
>
> If we can agree that it is not about facts, but about opinion, there are
> still fundamental arguments against SE-0117:
> Those who have issues with subclassing can just resign from it (as users
> of a library), and they can annotate their classes to dictate their usage
> (as an author) — but if you think subclassing is still a good tool, you
> can't do anything with a sealed class.
> Additionally, please note that those who ask for stricter rules and more
> regulation have many reasons to be happy with the status quo:
> You can subclass neither structs nor enums, and by default, you can't
> inherit from a framework-class as well, because it is internal — and yet
> they yell for more.
>
> Swift claims to be opinionated, not to aim for compromise — but if plain
> old OO isn't compatible with the ideals of the language, it would be more
> honest to just completely remove inheritance instead of slowly crippling
> it's possibilities.
>
> - Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/ae1d7384/attachment.html>