<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Em seg, 29 de fev de 2016 às 17:20, David Scrève <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Actually, I don’t understand the opposite that is made between Extension (that is ported by POP) and Specialization (ported by inheritance).<br>
<br>
Many OOP missed extension concept and developer mis-use inheritance to make extension…but having both concept allow to use properly extension and inheritance.<br>
<br>
If you make inheritance not fully operational, Swift will have exactly the same problem : people will try to make specialization with extension (using POP) whereas they should use inheritance.<br>
<br>
In addition, I thing adding stored property to protocol create a new question : Why using classes if protocols provide the same feature ?<br>
<br></blockquote><div><br></div><div>Protocols are not concrete types, at some point you will choose if will use a <u>reference type</u> or a <u>value type</u> to implement this protocol, and then, inherit this "default" properties.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
<br>
David<br>
<br>
<br>
> Le 29 févr. 2016 à 17:50, Pierre Monod-Broca via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :<br>
><br>
><br>
>> Le 26 févr. 2016 à 16:46, Evan Maloney <<a href="mailto:emaloney@gilt.com" target="_blank">emaloney@gilt.com</a>> a écrit :<br>
>><br>
>>> Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :<br>
>>> - with protocols + extensions, you write in once and apply it to each of your subclasses<br>
>>> - with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses<br>
>><br>
>> That's a problem with class hierarchies in general, not with abstract classes.<br>
><br>
> Yes, but that's not my point, I'm just answering "what's the difference"<br>
><br>
>><br>
>> You can use the same argument to call for the removal of classes from Swift,<br>
><br>
> It's going a bit far, inheritance has its own advantages in other situations.<br>
><br>
>> which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?<br>
><br>
> Good question. I would think so, but only as much as structs, enum and protocols.<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">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" target="_blank">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>
</blockquote></div></div>