Hacker News Reader

Comment by devit | Hacker News Reader

Final by default is correct, since otherwise you are effectively exposing and having to maintain an extra stable API towards subclasses, which is a nightmare and won't be done properly unless it's intentional.

In fact, having virtual methods at all outside of interfaces/traits/typeclasses is dubious language design since it meshes together the concepts of interface and implementation and makes it inconvenient, impossible or confusing to name the implementation instead of the interface.

The issues in the discussion are instead due to Apple's framework code being closed source and unmodifiable by users and developers, and also buggy according to the author.

View on HN

I'm an app developer. This change will absolutely break some of my stuff, and it's going to suck. Even with that, I do feel OP is taking an overtly political stance (even using the word "banned".) This change is perfectly reasonable within the already-strict mindset of Swift. Having a less-strict language just to work around potentially buggy Apple frameworks would be setting a bad precedent.

Using "final" also has some performance wins by reducing dynamic dispatch. [1]

[1] https://developer.apple.com/swift/blog/?id=27

What will it break? Name one single thing.

Remember, the only change here is the _default_ for classes that don't specify it. As I stated on the list earlier, I guarantee you 100% that when Apple starts vending framework classes written in Swift they will make an intentional decision on every single class as to whether it is final or not. And the language default won't impact that at all.

If Swift changes the default, do you think they'll Audit all of UIKit and AppKit to fix it? They're still transitioning things over to Swift piece by piece still. I imagine they'll let defaults work the way it is unless there is a good reason not to.

Being able to run-time patch an API installed on a device is an entirely different thing than being able to modify and distribute an open source framework.

Both are useful but they aren't the same thing. In one case, you want to able to get your code running on devices that in the wild now. In the other, you want your fixes to go upstream so you can remove any hacks needed to do the former.

> since otherwise you are effectively exposing and having to maintain an extra stable API towards subclasses

How so? I override what i want at my own peril. I'm not going to complain to the author that his change broke my code.

> Apple's framework code being closed source and unmodifiable by users and developers, and also buggy according to the author.

Apple is constantly breaking things. If we can't extend classes, then we'll use composition and at the end of the day, what's the difference? I need code that sits in front of there so I can make it work correctly.

Reply on news.ycombinator.com