[swift-evolution] [Review] SE-0026 Abstract classes and methods

Austin Zheng austinzheng at gmail.com
Thu Mar 3 15:26:33 CST 2016

Without getting into a protracted argument, I just want to reiterate that:

* Foundation and Cocoa remain (and will remain for years) a critical part
of Swift software development.
* These frameworks are built around inheritance hierarchies; what you can
do to retrofit POP onto them is quite limited. If I want a partially
customized UIView that makes changes through the existing API hooks I'm
going to subclass, not create a protocol.
* These frameworks already contain classes and methods that are 'abstract',
where that status is enforced through documentation or runtime asserts.
This is, in my opinion, a hole that should have been filled a long time ago
(but, for various technical reasons, couldn't); we have a chance now to do
exactly that.

In terms of whether or not it's worth making changes to Swift et al 'just'
to improve Objective-C interop...I think the community has pretty much
decisively come down on the side of yes (see: typed selectors, importing of
user-defined Objective-C generics as Swift generics, systematic renaming of
imported Objective-C method names to conform with Swift compatibility...).


On Thu, Mar 3, 2016 at 12:55 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Mar 3, 2016, at 12:42 PM, Evan Maloney <emaloney at gilt.com> wrote:
> >
> > There has been a proposal floated (by Dave Abrahams if I recall--and if
> I'm wrong, sorry!) to change protocols so conformance is NOT inherited by
> subclasses by default.
> >
> > I would just like to point out that if that happens, all of the
> arguments against abstract classes go out the window, and we absolutely
> WILL need abstract classes, because all the convoluted gymnastics required
> to get protocols to kinda-sorta (but not really) provide some of what
> abstract classes provide won't be possible.
> >
> > Long live the class hierarchy!
> That was me. I only proposed it as an *option* for the conformer, though,
> not as a sweeping change.
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/c418a0ea/attachment.html>

More information about the swift-evolution mailing list