[swift-evolution] Final by default for classes and methods

Javier Soto javier.api at gmail.com
Sun Dec 20 15:33:29 CST 2015


and you get to test betas of future iOS releases anyway, so if something
breaks, you'll catch it and release a fix.

That assumes that all apps get updated when new OS releases come out, and
that's not true. Many apps stop being maintained, but they may have many
users, and Apple does whatever they can to make sure apps don't break when
users update iOS. The reality is that Apple spends a lot of time working
around hacks implemented in apps like swizzling, etc.

I'm really worried about the world where monkey-patching iOS internals is
no longer possible

I'm excited about that world, because Apple won't have to waste time
worrying about ugly hacks, and they can focus on fixing bugs instead.

In any case, this proposal is about final by default. Final is already part
of the language, and I'm sure Apple wouldn't hesitate to use it extensively
when/if they write frameworks in Swift, so I don't think this proposal
would change that.
On Sun, Dec 20, 2015 at 1:17 PM Andrey Tarantsov <andrey at tarantsov.com>
wrote:

> This is another proposal that's right on principle, but breaks down in
> real-world scenarios.
>
> To play devils advocate, take for example UINavigationController in UIKit
> on iOS.
>
>
> This.
>
> Real iOS apps subclass and override things that were never supposed to be
> overridden, swizzle iOS internals and do a lot of other nasty stuff,
> because sometimes that's the only way to get the effect you want, and you
> get to test betas of future iOS releases anyway, so if something breaks,
> you'll catch it and release a fix.
>
> I'm really worried about the world where monkey-patching iOS internals is
> no longer possible. Thankfully, a Swift-based UIKit isn't anywhere on the
> horizon.
>
> ON THE OTHER HAND, I do agree with this proposal for our own code. I've
> always used
>
> // override point
>
>
> to mark methods designed to be overridden, and a keyword to document this
> formally would be appreciated.
>
> A.
>
> --
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/5be0b2af/attachment.html>


More information about the swift-evolution mailing list