> On Jul 16, 2016, at 9:05 AM, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
