Sent from my iPad
> On Jul 5, 2016, at 8:53 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> * What is your evaluation of the proposal? >> >> I think it's ultimately a good idea. Being noncommittal about >> subclassability/overridability—and thus forbidding it in public scope, but >> not making any promises about what the module does internally—is the >> alternative that preserves the most freedom for the module, and therefore >> the most appropriate default. >> >> However, I don't like the `subclassable` and `overridable` keywords. They >> read like opposites of `final` with no implications for access level; I >> could easily imagine somebody marking an internal class `subclassable` >> assuming that it merely means it can be subclassed internally, and being >> very surprised (or even not noticing!) that the class has been made public. >> They're also long and cumbersome; that might be seen as a positive, but I >> think it will increase the inevitable backlash against this change. >> >> I prefer the keyword `open`, which sounds like it could be a statement about >> the item's accessibility—and even sounds like it ought to be "more public >> than public"—and is short enough that it ought to be difficult to grumble >> about the change. It also means that both classes and members use the same >> keyword, and gives us a keyword that we can later use to "open" other things >> in the language, such as allowing you to extend enums with new cases. > > Agreed; I also prefer "open" to having two different long keywords that don't > (at least to my ear) imply "public". +1. I agree that the keywords in the proposal don't feel like they imply public and do feel like they might be required even internally, a really unfortunate combination. > >> I think Kevin Lundberg is right to worry about testability, but I don't >> think that has to prevent this change. Instead, we should permit `@testable` >> imports to subclass/override things that are not publicly >> subclassable/overridable, and thus a module built with "Enable Testability" >> on can't actually assume there are no subclasses/overrides of `internal` >> classes/members even if it doesn't see any. This will block optimizations in >> debug builds, but not in release builds. The proposal should be edited to >> explain this `@testable` behavior. > > IIUC the basic design of @testable is to treat the tests for the testable > thing as existing within its module, so I think this just falls out. I agree > that it should be spelled out in the proposal, though. > > John. > _______________________________________________ > 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
