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

[John McCall]

> On Jul 16, 2016, at 9:05 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 	* 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 talk about this in the proposal; this is a possible avenue of future extension.  I wanted to keep this proposal small, and requiring the whole hierarchy to be open avoids a number of design problems.
 
> 	* 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?

There is no "sealed" keyword in the proposal.

Since we're naming open "open", if we need a reverse, we would probably use "closed" or "nonopen" for it.  "sealed" is a common term for this kind of feature, and it's the one we've been using in this discussion, but unfortunately "sealed" is not a natural opposite of "open".

John.

> 
>> 	* 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
> 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/20160716/eba357a5/attachment.html>