[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall]

> On Jul 5, 2016, at 9:11 PM, Kevin Lundberg <kevin at klundberg.com> 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 <swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>