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

[Kevin Ballard]

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.api at 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 <tomas at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/5a1eb8c3/attachment.html>