> * What is your evaluation of the proposal?
+1 as before but I do have concerns
* Why do open classes need to have also have open superclasses?
* I don’t think sealed methods/properties as default is the right
default.
* If the default was open for methods/properties, then do we really
need the sealed keyword? Could’t we just use final for that?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes
> * Does this proposal fit well with the feel and direction of Swift?
Requiring super classes to also be Open seems wrong.
I agree with Kevin Ballard on being open by default for methods/ properties
http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/
<http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/>
If we are open by default for methods/properties then we could simplify things
by just using final for methods that need to be sealed; I don’t see the need to
have sealed methods/properties outside of the module ONLY.
We already have to mark all public methods/properties as public, if I need
something not the be overridable then I can just use final. This would work the
same across all classes.
If I was a framework author that initially just had a library that was sealed
but then somebody asked me to make it open; All I would want to do is add open
to the class only, I would not want to spend the time to go back an add open to
all public methods/properties specially if I am already using final. I think
having method/properties open by default is the best compromised. I can see
framework authors switching a class to be open and expecting that everything in
the class in open and if they don’t open any methods, then what possible use is
a subclass than an extension could not provide? I think that is an overreach to
make the framework author have to add open to every public method in addition
to having to open every super class. As a framework author if I think my
clients could use subclassing, all I want to do is flip a switch on the classes
that I want to make subclass able and then just push a new version. As a
framework user I want to be able to tell my framework author “can you just add
open to classes abs and deca etc.” I think it is more likely that I will get my
request if it is easy vs it the framework author needs to touch every class in
the hierarchy.
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
n/a
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
reviewed previously and followed the update.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
