[swift-evolution] Final by default for classes and methods
javier.api at gmail.com
Mon Dec 7 22:38:19 CST 2015
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
> > 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution