[swift-evolution] [Proposal draff] abstract classes and methods

Gwendal Roué gwendal.roue at gmail.com
Thu Jan 7 12:57:27 CST 2016

> Le 7 janv. 2016 à 19:44, Matthew Johnson via swift-evolution <swift-evolution at swift.org> a écrit :
>> On Jan 7, 2016, at 12:42 PM, David James via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Not sure the language direction should encourage inheritance based structures, which abstract classes and methods do. That’s not to say that inheritance is dead, but that a modern language should encourage and support compositional patterns rather than inheritance based patterns. 
> +1 to these comments.  This proposal notes that protocols would provide very similar behavior if they were allowed to have stored properties.  That has already been discussed a little bit.  I think it would be best to decide whether that will happen or not before introducing abstract classes and methods.

I agree that the support for stored properties in protocols should definitely help avoiding the need for an abstract classes in many cases.

The problem, though, is that abstract classes still have something that protocol do not, and this is the encapsulation of implementation details. Protocols, on the other side, are open in the wide, expose all their inner guts. The problem with convenience protocols that expose too much implementation details is that they make refactoring very difficult, if possible at all. Abstract classes don’t have this issue.

So I think protocols still have a long, long, way before they can match abstract classes.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/14a50664/attachment.html>

More information about the swift-evolution mailing list