> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution > <[email protected]> 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`. 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
