[swift-evolution] Final by default for classes and methods
David Owens II
david at owensd.io
Mon Dec 7 13:30:21 CST 2015
The problem is that this perpetuates the fundamental problem with type hierarchies: the further down the rabbit hole you go, the more fragile your types end up being.
I’d much rather design for inheritance rather than having it be opt-in by-default. I really like the inheritable only from within the module by default idea that Joe and Slava mentioned.
> On Dec 7, 2015, at 11:21 AM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
> Resending to whole list:
> I can appreciate the desire for this, but I would not support it personally. In a former life developing C# code where this is the default behavior, I wanted to extend a class's behavior to make it work slightly differently, but since everything is final by default (sealed in C# parlance) I was prevented from doing so. The scope of my change was minimal and well defined, and it would not have negatively impacted the extending class's normal behavior. The code I was extending was open source so i ended up having to copy and paste the class and its dependencies into my project to do what I wanted. If I couldn't have done that then I'm not sure what the right approach would have been.
> In short, it is not always possible to know ahead of time how your clients will want to extend your API's functionality; artificially limiting this in my opinion will make it much harder to reuse components in previously unforeseen ways.
> Kevin Lundberg
> On Dec 7, 2015, at 2:12 PM, Javier Soto via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> This was brought up in a different thread about private by default. Creating a new thread for this. Quoting Mathew from the other thread with a short summary about the motivation behind this:
>> "It is not uncommon to have a need for a reference type without a need for inheritance. Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design."
>> Javier Soto
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution