> On Jul 5, 2016, at 9:11 PM, Kevin Lundberg <[email protected]> wrote: > > 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.
Our testing design is only intended to allow first-party tests to break the normal access restrictions. It seems to me that other tests should be treating their external dependencies as black boxes and use their normal API. John. > > > 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 >>> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
