[swift-evolution] [Draft] Allow declaration of abstract functions and properties on classes

Vinicius Vendramini vinivendra at gmail.com
Mon Feb 29 12:13:41 CST 2016

You do have a point here. For some reason I was thinking that structs also supported inheritance - in which case it made more sense to me to add the feature to protocols, so that structs could use it too.

In that case, I’m sold on implementing this in classes instead of protocols. +1 from me :)

As a side note, being able to constrain protocols to subclasses might be something interesting to pursue later.

> On Feb 29, 2016, at 1:00 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
> I think that the current approach of wishing protocols could basically do everything might be adding too much responsibility and complexity to the POP pattern, but I think both inheritance and protocol oriented programming should receive equal care at this point. Better access control for properties and methods as well as abstract classes are a way to improve inheritance/OOP that is sorely needed and we should discuss improvements to protocol in their own context... without snide remarks on how improvements there actually negate a feature somewhere else. 
> I think we need to move forward from the OOP vs POP debate, I do think Swift can support and evolve both approaches... 
> Sent from my iPhone
> On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution <swift-evolution at swift.org> wrote:
>>> You can write class-only protocols in Swift.
>> I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
>> The latter would need to needless conceptual leakage.
>>> 2016/02/29 11:27、Evan Maloney via swift-evolution <swift-evolution at swift.org> のメッセージ:
>>>>> I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, I’m starting to agree that this is an important language feature indeed, since I can’t think of any better (or even equivalent) way of solving the example you showed.
>>>> I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
>>>> Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
>>>> It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list