The compiler doesn't complain, and presto, I've totally broken this method, which is now a NOP throughout my code. I didn't have to say "override", so I had no idea I was doing this; and even if I know about it, I can't mend the problem, because the extension won't let me call `super` (well, it will, but it thinks `super` is UIControl, not UIButton).
Is this intentional, and if so, what's the intention?
(Note that this is a different issue from the question of whether I can extend a class and then subclass to override the extended functionality within the subclass.)
The text was updated successfully, but these errors were encountered:
In your first example, you haven't overridden test. Any existing code that's out there calling test will still be calling the original implementation. What you've done is add an overload for test.
In the second example, however, you're dealing with an Objective-C class. Methods in Objective-C are called by selector, which means that extensions can stomp on existing implementations. (This is a big problem when the "existing implementations" aren't public, which is why we chose a different approach for pure Swift methods.)
This probably does deserve better documentation. @natecook1000, where should that go?
"out there" = "compiled without importing your app module" (so, any code that's in the framework).
It's a longstanding hole in the language that we don't have a way to say, e.g. c.MyCoolFramework::test() vs. c.MyApp::test() like we do for top-level values. Right now I believe the compiler resolves the ambiguity by always preferring the current module over other modules, but if you try in a unit test, for example, you should see the ambiguity you expect.
This feature in general, though, is important for Swift frameworks eventually being part of the SDK, so that when Apple (or someone) adds a new method to a class, it doesn't break your built apps. It's a place where Swift can do better than Objective-C.