Overriding is not normally how you test classes to begin with. The traditional Obj-C way of testing classes like that is to use a mocking library, that provides NSProxy objects that forward non-stubbed methods to the original class (or forward everything and merely record which methods were invoked). This of course only works for classes that use the Obj-C runtime.
The approach that is often recommended for Swift is to use protocol- oriented programming, where you expose things as protocols instead of as classes. That way you can provide your own implementation of the protocol in order to mock something out. -Kevin Ballard On Mon, Dec 21, 2015, at 09:35 AM, Tomáš Linhart via swift-evolution wrote: > But tell me how will you test your code that is depending on a class > provided by external party? You cannot subclass so you cannot override > the behaviour that you need stub, at the you will wrap entire library > in your own classes that you can subclass but what for? Subclassing > rarely breaks things and if it does, you should mark it final but it > shouldn't be explicit. > > Tomáš > > On Mon, Dec 21, 2015 at 6:31 PM, Javier Soto > <javier....@gmail.com> wrote: >> I think it's just as important for methods. If you make a class >> final, all methods become final, so that's OK. But if you make a >> class subclassable, and then forget to mark some of it's methods >> final, then all methods would be overridable which is probably not >> what you'd want in must cases. On Mon, Dec 21, 2015 at 9:19 AM Tomáš >> Linhart <to...@linhart.me> wrote: >>> Hello, >>> >>> I must say, I am not big fun of this proposal because currently in >>> Swift only way how to mock classes is to subclass them. If this >>> proposal becomes reality, it will make mocking of all third-party >>> libraries impossible unless they mark their classes non-final and I >>> am afraid authors will just use the default behaviour so at the end >>> people will stop testing code that is using third-party libraries or >>> they will have to fork the libraries or ask the authors. This can be >>> fixed by having better testing support in Swift but I don't think, >>> this will happen anytime soon. >>> >>> I would rather see introduction of better reflection so mock >>> frameworks can be reality. I would like to see also other building >>> block of objected-oriented-programming such as abstract classes, >>> protocols with generic type parameters and not just abstract types >>> (associated types) that allows to design better APIs that don't >>> depend so much on overriding regular classes. >>> >>> >>> Tomáš >>> >> >> -- >> Javier Soto >> > > _________________________________________________ > swift-evolution mailing list swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution