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

James Campbell james at supmenow.com
Tue Dec 22 07:00:05 CST 2015


I like the point someone made about unit testing. If subclassing was
disabled then I think there should then be some way of mocking built into
the testing frameworks of swift (Think RSpec but for switt)

On Tue, Dec 22, 2015 at 12:51 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On Dec 22, 2015, at 3:43 AM, Tino Heth <2th at gmx.de> wrote:
>
>
> I can see why you view it this way, but access control and inheritability
> are orthogonal.
>
> as I understand orthogonal (mathematical background), it is definitely not
> the case:
> I can't inherit what I cannot access, so there is one impossible
> combination of the two attributes.
>
>
> Ok, you got me there.  Orthogonal was not the best choice of words.
> Nevertheless, they are independent concerns that happen to interact in this
> one case.
>
>
> The argumentation that "users of your framework could cause trouble (what
> they will do anyways ;-) with overriding" looses traction when you have to
> add "of cause that only applies to classes you made explicitly accessible
> to them".
>
> Final is right in theory, but in real software, classes are rarely
> designed for inheritance — it just happens (and I'm quite sure most real
> software is build by people who would shrug of such discussions as academic
> nonsense ;-).
>
>
> If the time comes it is certainly a good thing if the language can remind
> you of the fact that you didn't consider it in the initial implementation
> by requiring you to mark the superclass inheritable.
>
>
> Btw: I wouldn't oppose a proposal to allow changing conventions like this
> (there are at least two other discussions about the best default) on a per
> module/file basis — as long as the "local" effect of the setting isn't
> vital, there shouldn't be a problem with customizing.
>
>
> I would really be opposed to this.  It would not be clear when reading
> code what it actually means.  Copy and paste would also be problematic for
> similar reasons.  Flags should not change the semantics of a piece of code.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/5548654a/attachment.html>


More information about the swift-evolution mailing list