<div dir="ltr">@Goffredo: +1 for all you said. Well said. :-)<div><br></div><div>-Van</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 3:00 PM, Goffredo Marocchi via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
I think we need to move forward from the OOP vs POP debate, I do think Swift can support and evolve both approaches...<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> You can write class-only protocols in Swift.<br>
><br>
> 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.<br>
><br>
> The latter would need to needless conceptual leakage.<br>
><br>
><br>
>> 2016/02/29 11:27、Evan Maloney via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br>
>><br>
>>>> 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.<br>
>>><br>
>>> I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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).<br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>