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

[Javier Soto]

Love it 👍
On Mon, Dec 7, 2015 at 8:30 PM John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> Defaults of public sealed/final classes and final methods on a class by
> default are a tougher call. Either way you may have design issues go
> unnoticed until someone needs to subclass to get the behavior they want. So
> when you reach that point, should the system error on the side of rigid
> safety or dangerous flexibility?
> >
> > This is a nice summary of the tradeoff.  I strongly prefer safety myself
> and I believe the preference for safety fits well with the overall
> direction of Swift.  If a library author discovers a design oversight and
> later decides they should have allowed for additional flexibility it is
> straightforward to allow for this without breaking existing client code.
> >
> > Many of the examples cited in argument against final by default have to
> do with working around library or framework bugs.  I understand the
> motivation to preserve this flexibility bur don't believe bug workarounds
> are a good way to make language design decisions. I also believe use of
> subclasses and overrides in ways the library author may not have intended
> to is a fragile technique that is likely to eventually cause as many
> problems as it solves.  I have been programming a long time and have never
> run into a case where this technique was the only way or even the best way
> to accomplish the task at hand.
> >
> > One additional motivation for making final the default that has not been
> discussed yet is the drive towards making Swift a protocol oriented
> language.  IMO protocols should be the first tool considered when dynamic
> polymorphism is necessary.  Inheritance should be reserved for cases where
> other approaches won't work (and we should seek to reduce the number of
> problems where that is the case).  Making final the default for classes and
> methods would provide a subtle (or maybe not so subtle) hint in this
> direction.
> >
> > I know the Swift team at Apple put a lot of thought into the defaults in
> Swift.  I agree with most of them.  Enabling subclassing and overriding by
> default is the one case where I think a significant mistake was made.
>
> Our current intent is that public subclassing and overriding will be
> locked down by default, but internal subclassing and overriding will not
> be.  I believe that this strikes the right balance, and moreover that it is
> consistent with the general language approach to code evolution, which is
> to promote “consequence-free” rapid development by:
>
>   (1) avoiding artificial bookkeeping obstacles while you’re hacking up
> the initial implementation of a module, but
>
>   (2) not letting that initial implementation make implicit source and
> binary compatibility promises to code outside of the module and
>
>   (3) providing good language tools for incrementally building those
> initial prototype interfaces into stronger internal abstractions.
>
> All the hard limitations in the defaults are tied to the module boundary
> because we assume that it’s straightforward to fix any problems within the
> module if/when you decided you made a mistake earlier.
>
> So, okay, a class is subclassable by default, and it wasn’t really
> designed for that, and now there are subclasses in the module which are
> causing problems.  As long as nobody's changed the default (which they
> could have done carelessly in either case, but are much less likely to do
> if it’s only necessary to make an external subclass), all of those
> subclasses will still be within the module, and you still have free rein to
> correct that initial design mistake.
>
> John.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/e3d784b6/attachment-0001.html>