> On Jul 25, 2016, at 6:38 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> * What is your evaluation of the proposal? > > Of the designs offered, I prefer #1, because: > > 1. I'm not convinced that there's actually any sense in subclassing a class > with no open members; it seems to me that any class intended to be used like > this ought to be redesigned to use composition instead of subclassing. > > 2. I also think that you're still effectively depending on implementation > details about the instance's lifecycle. Suppose I write a database library > which has a Record class. It supports uniquing—that is, a single database > record is never represented by two different Record instances. If the last > external reference to a Record disappears, does the library hold onto that > Record and return it again in response to another query, or does it > deallocate it and create a new one? That barely matters *unless* you've > subclassed Record. > > 3. Even if there are no overrides, the class and the library around it > probably still need to be designed for subclassing. Take the Record example > from the previous point: the library will never use your subclass unless > there's some hook for telling it which subclass to use. Subclassing isn't > going to actually work right if the library doesn't expect any subclasses. > > 4. Even leaving that aside, you may still foisting surprising memory > characteristics on the library. For instance, you might hang a large object > graph off an instance that's intended to be lightweight, or create a retain > cycle the library author took great pains to avoid. > > 5. Finally, this doesn't help with the stated goal of allowing you to make a > class `final` in a later version of the library. > > However, I'm actually strongly in favor of Garth Snyder's call for `open` to > explicitly become an access level. In design #1, it almost is already; making > it official would simplify many aspects of this design. > > (If we do take that road, I would further suggest requiring protocols to be > marked `open` instead of `public`. I can easily imagine having closed > `public` protocols which are visible but can't be conformed to; this would > help with certain typing problems, such as `CKRecordValue`. On the other > hand, if `public` were conformable from outside, I can't think of a use for > marking a protocol `open`.
I am very much interested in introducing closed protocols. This seems like an interesting and reasonable way to approach it. I like that it makes the choice explicit across module boundaries with no real “default” to speak of - there is no additional “burden” (boilerplate) placed on either decision. > > Protocol extension members should continue to be marked `public`. I could > imagine `open` being added later, meaning that the member should be added as > a protocol requirement so a specialized implementation can be provided; this > would avoid the current boilerplate for defaulted protocol members.) > >> * 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? > > Yes. > >> * 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? > > I put a little bit less effort into this review than I did into the previous > two reviews, the many discussion threads on this topic, or several months of > thinking this over and changing my mind about the idea as the plan evolved. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
