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

[James Campbell]

Personally I think a great compromise is just forcing the user to use the
`override` keyword when subclassing in these cases. That way the library
maker can mark classes that aren't supported or are internal and ideally
shouldn't be used by the programmer.

However we shouldn't baby sit programmers, we are smart people after all.
So if there is a huge catastrophic bug that just happens to be easily
solvable by subclassing or whatever then we should allow them to do so.

An `override` keyword would be a great compromise, take this class:

public class NonSubclassableParentClass {

}


If the programmer subclasses it normally, the compiler will throw an error
telling them to use the `override` keyword to subclass non-subclassble
classes:

override class  MySubclass: NonSubclassableParentClass {

}


Now there is a clear indicator that we are doing something not safe or
ideal here. This is similar how the "!" in IUO indicates we have a unsafe
value. We are grown-ups we should be able to know when to subclass but this
doesn't mean there couldn't be something like this to indicate to the user
that they may want to revaluate this in the future.

So in the future other programmers can see this marker and think "Oh we are
using this class in a non recommended way, so when it breaks when I upgrade
the library it's our fault." hopefully making them continue to upgrade
rather than not upgrading because it breaks "my subclass".

Whats great about this feature is it also allows linters or the compiler to
also show warnings when this is used as well, that way those of us that are
bugged by the amount of warnings we have in our app can endevour to fix it.

In Ruby there is a convention to have these sort of monkey patches and
subclasses to fix bugs in a special folder with "_ext" after it to indicate
that this an extension to a class from a library, this indicates to the
programmer that it's something we should ideally remove as soon as the app
can work without that hack.

So I can't see why we can't have this `override` keyword to tell the
library developer that we like to live life on the edge a litte ;)


*___________________________________*

*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 8 July 2016 at 22:14, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

>
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe
> there would have been significant benefits to Apple's platforms and
> ecosystem.  The reasons for believing (or not believing) this have been
> discussed in depth so there isn't a need to rehash them now.
>
> I'm not asking for reasons but for a single persuasive example…
>
> It is easy to claim that everything will be better if we add restrictions,
> but so far, I haven't heard of any real problems cause by the current
> defaults:
> The motivation to change them is not because of actual experience, it's
> just the trendy opinion that inheritance is evil.
>
> _______________________________________________
> 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/20160708/7f0a8cdb/attachment.html>