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 <[email protected]>
> のメール：
>
> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
