I hadn't considered @testable, and it may be one way to mitigate the trouble this could cause in tests, so thank you both for bringing it up as the proposal should definitely account for it. I'm curious though how this would solve the case of trying to subclass a module's class in a test where you don't have the source? If you don't have control over the source, you can't rebuild it to enable testability, and it might even be desirable for someone to refuse to distribute a binary with testability enabled if doing so might reveal proprietary information or lead to a possible security problem with their library.
On 7/5/2016 9:53 PM, John McCall via swift-evolution 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". > >> 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
