> Am 06.07.2016 um 13:39 schrieb Matthew Johnson via swift-evolution > <[email protected]>: > > > > Sent from my iPad > >> On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution >> <[email protected]> wrote: >> >> Huge +1. >> >> Question about inheritance though: >> >> class A {} // Not publicly subclassable >> subclassable class B: A {} // Publicly subclassable >> class C: B {} // Not publicly subclassable? Or is the subclassability >> inherited? > > This is a great question. There are really two questions: > > Can B be marked "subclassable" even though its superclass isn't? Allowing > this allows creation of new classes with A as an ancestor. Since this is > explicitly opt-in all within the same module I'm inclined to say we should > allow it. > > Is subclassability inherited by in-module subclasses? This seems to me > opposed to the spirit of closed by default. I think it is better to require > annotation on *every* class an method that is open to extension outside the > module, regardless of what choice a superclass makes, > > This gives module authors the most control over *exactly* which classes can > be used as superclasses outside the module (A and C don't need to be > subclassable just because B needs to be.
I totally agree with both points. -Thorsten > > -Matthew > >> >> I'm not a big fan of the subclassable keyword either since it's quite long, >> not to mention it contains "class" which is the next keyword, making it >> visually repetitive. >> >> I'd prefer open on both class and func to introduce only one keyword instead >> of two and possibly make it as a modifier of public to keep it in line with >> private(set)... >> >>> On Jul 6, 2016, at 1:11 AM, Chris Lattner via swift-evolution >>> <[email protected]> wrote: >>> >>> Hello Swift community, >>> >>> The review of "SE-0117: Default classes to be non-subclassable publicly" >>> begins now and runs through July 11. The proposal is available here: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md >>> >>> Reviews are an important part of the Swift evolution process. All reviews >>> should be sent to the swift-evolution mailing list at >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> or, if you would like to keep your feedback private, directly to the review >>> manager. >>> >>> What goes into a review? >>> >>> The goal of the review process is to improve the proposal under review >>> through constructive criticism and contribute to the direction of Swift. >>> When writing your review, here are some questions you might want to answer >>> in your review: >>> >>> * What is your evaluation of the proposal? >>> * Is the problem being addressed significant enough to warrant a change >>> to Swift? >>> * Does this proposal fit well with the feel and direction of Swift? >>> * If you have used other languages or libraries with a similar feature, >>> how do you feel that this proposal compares to those? >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >>> >>> More information about the Swift evolution process is available at >>> >>> https://github.com/apple/swift-evolution/blob/master/process.md >>> >>> Thank you, >>> >>> -Chris Lattner >>> Review Manager >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
