[swift-evolution] Final by default for classes and methods
Roopesh Chander S
roop at roopc.net
Thu Dec 24 07:05:37 CST 2015
> On 24-Dec-2015, at 9:34 AM, Andrey Tarantsov <andrey at tarantsov.com> wrote:
>>
>> 2. If I'm releasing a Swift binary framework, and I haven't yet thought about which classes / methods should be overrideable, should I release it in
>> everything-is-overridable mode, or in nothing-is-overridable mode?
>
> That's a tricky one. Ideally you would pretend that nothing is overridable, but some hack like @testable makes everything overridable when really needed.
One point of view mentioned earlier is that by the time we’re onto writing frameworks that aren’t meant to be used from Obj-C, we can use protocols all the way. You can test by providing a mock implementation of the protocol - the “Crusty" talk in the last WWDC talks about this briefly.
>
>> 3. If I'm using a third-party (non-Apple) Swift binary framework, and if the framework author hadn't really thought about which classes / methods should be overrideable, would I want the power to override everything in the framework now?
>
> Yes. There were many cases where fixing up a pod was just an important as fixing up an Apple framework.
>
> Yes, I have an option to change the source — but it's vastly more labour-intensive if all you need is a simple isolated change. (Especially if that change isn't likely to be accepted upstream.)
>
>> (Note that if I get that power, I forgo all hope of getting a binary-compatible update to the framework with correct annotations about which classes can be safely overridden and which aren't meant to be overridden.)
>
> Sure, and that doesn't matter because all frameworks are built with your app anyway.
>
>> A3: Ideally, I'd like to be able to override everything in the framework I use, but if that implies that I can't get a binary-compatible fix to the framework, maybe I can live without that overridability.
>
> Why would you want binary compatibility for non-Apple frameworks? It's not like you can install them globally (or would want to, even if you could).
>
If I got v1.0 of a binary framework and wrote code that worked with that, and then upgrade to v1.1 for some fixes and find that my code doesn’t compile anymore (say “Error: You can’t inherit from NewlyFinalizedClass”), I wouldn’t like that.
roop.
More information about the swift-evolution
mailing list