> On Jul 14, 2016, at 11:39 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > To sum this all up, the core team is rejecting this proposal and requesting a > revision to change the concrete syntax to “public open class Foo” instead of > “subclassable class Foo". This approach satisfies the *unwavering* goal of > requiring additional thought when publishing a class as public API, makes > subclass-ability orthogonal to access control, and (admittedly as a bit of a > swift-evolution process hack) asks the community for an in-depth discussion > of the secondary points of the proposal: does it make sense to require every > member to be marked as “overridable” in order to be overridden by an open > subclass outside of the current module?
+1 on open instead of subclassable. As per the overridability I'm coming back and forth. There are certainly classes where you want just a few things to be overridable and then there are classes where you want almost everything overridable. I would personally prefer not overridable by default, but also an addition of a modifier on open that would allow to specify default overridability: // by default everything is overridable open(override) class Bar Alternatives: open(members), open(all) This, however, requires a new keyword for "closing" a member within the module: // Not allowed overriding beyond the module. closed func foo() BTW I'm not a fan of the keyword "overridable" at all. Imagine that you subclass the class in another module, override the method and expose it for yet another module and keep the overridability: overridable override func foo() I'd prefer the open keyword to be reused here. > > -Chris > > _______________________________________________ > 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
