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

Sun Jul 10 07:01:30 CDT 2016

This has been a very interesting and educational thread.
Thanks to everyone who kindly replied to me and explained things.

Here is my 2¢…

>  * What is your evaluation of the proposal?
+0 as it stands… 
+1 if there could be a reliable way for us to explicitly un-seal a sealed class for those times where its absolutely necessary.

If its at all feasible… maybe something like ...

public class MyWorkaroundClass : @forceOpen(YourSealedClass) {  //Obligatory Compiler Warning Occurs    
    public override func @forceOpen(brokenFunc()) {/*FIXME*/}
}
(The above is just a rough idea, please don't yell at me for the ugliness... 🙂)

Just like we have forced unwrapping of optionals (for only when we really need it), I believe that we should be able to force unseal when we truly need it;

Another +1 if the keyword is changed from subclassable/overridable to something less confusing… since people might be easily be misled and think that even within thier own module if they don't mark it subclassable it won’t be subclassable… perhaps "open" is the better keyword…

public open class MyOpenClass {      
    public open func openFunc() {/*OVERRIDE ME!*/}
}
In this case, "open" can only apply to public classes/methods/accessors, anything else using "open" ("private open" etc) will be an obvious error.

Please note that I am not against this proposal in theory; only that I would humbly request that the two items above be at least considered and I will happily jump on board.

>  * Is the problem being addressed significant enough to warrant a change to Swift?
I do think it is, because the potential upsides are many, such as better fencing between modules and users of those modules, potential performance gains and making it more explicit to a library writer what he/she is going to make public and also modifiable by consumers of the provided API.

Again though, I would be reticent to agree 100% if there werent a way to punch though that fence when we need to, not allowing such a thing makes the environment too rigid/unproductive and thats not the Swift I want to continue using. Swift is not C++ minus the C… is it?

>  * Does this proposal fit well with the feel and direction of Swift?
I think overall it does because swift encourages more ad-hoc composition than inheritance based, so making inheritability more explicit does seem to fit in with the direction of Swift… although the lack of ability to escape that limitation just like we have with forced unwrapped optionals makes me feel its at the same time not fully in line with the direction of swift… hence the +0 instead of a full +1.

>  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Someone here brought up Kotlin, but I have only dabbled with it.. It seems similar to that from what I can read… but I have no experience with writing or consuming a library in Kotlin.

>  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have been wrestling with this in my mind since late last year when it first appeared on the swift-evolution list as a general discussion. 
I was originally very very strongly -1 on this (especially coming from an Objective-C background), but after reading the proposal and everyones replies both for and against, and thinking again deeply about my own code, have come around to believe that there are potential gains for this that are worthwhile, but only if some flexibility remains in the language to work around classes that are both closed-source and has a defect that is needed to workaround though subclassing.
——

Pros
Better Fencing Between Modules
Potential Performance Gains
Subclassing is Discouraged Unless its Explicitly Thought About

Cons
Unable to Override a Method/Accessor on a Class that Needs Fixing but is Closed Source 
You are at the total mercy of the framework author… (this one is pretty big to be honest)

"Unknowns" that make it hard to judge...

What effect this will really have on the community… 
What true objective performance benefits we can expect from inter-module optimization…
Will this really make libraries any better?

——

Other thoughts...
While it can be said that because most libraries are open source, the need to subclass is lower now than ever -we can just go in and fix something and send a pull request-  those of us trapped in large corporations that have (usually poorly supported) SDKs shoved down our throats by the suits need a certain level of flexibility to work arounds things… 

In debating to support this or not, I am reminded of comments by many here: http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/

——

Thanks,

Andre

> 2016/07/06 8:11、Chris Lattner via swift-evolution <swift-evolution at swift.org> のメール：
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> 	https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> 	* What is your evaluation of the proposal?
> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 	* Does this proposal fit well with the feel and direction of Swift?
> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> _______________________________________________
> 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/20160710/700c6595/attachment.html>