Final by default for classes and methods


(Tomáš Linhart) #1

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áš


(Matthew Johnson) #2

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.

I agree. I am wondering if we should separate the two topics into distinct threads though. As this topic has most recently been focused on classes perhaps we should adjust the subject line and start a new thread focused on methods within classes that are not final.

···

On Dec 21, 2015, at 11:31 AM, Javier Soto via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Dec 21, 2015 at 9:19 AM Tomáš Linhart <tomas@linhart.me <mailto:tomas@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


(David Waite) #3

A proposal could allow subclassing final/sealed classes when using @testable import

-DW

···

Sent with my Thumbs

On Dec 21, 2015, at 10:18 AM, Tomáš Linhart via swift-evolution <swift-evolution@swift.org> 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áš

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Javier Soto) #4

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@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


(Tomáš Linhart) #5

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@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@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


(Lily Ballard) #6

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@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@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