<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Interesting approach…here, we prefer class approach to struct for 2 majors reasons :<div class="">1 - We usually use OOP and class is a common mechanism for us</div><div class="">2 - We reserve struct for small object because struct are value type and passing struct in parameter may be stack and time consuming.</div><div class=""><br class=""></div><div class="">Usually we design architecture of our product as something which is language independ. So the quality of a language is its ability to easily implement architecture concept that we’ve designed, but we thing that a language should not (or should have the less) impact the architecture that has been designed. </div>
</div><div class=""><br class="webkit-block-placeholder"></div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 28 févr. 2016 à 19:25, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-size:12.8px" class="">Some more ideas. I do not necessary look at them as arguments "for" or "against", and additionally I'm biased, as I've already said.</div><div style="font-size:12.8px" class=""></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">While there are many use cases for mixins and multiple inheritance, in many cases there is a superclass which is clearly predominant, almost like the classical animals, cats and dogs.</div><div style="font-size:12.8px" class="">Classes are a bit simpler to grasp for users of C++ and similar languages.</div><div style="font-size:12.8px" class="">My mixins proposal currently has issues regarding multiple inheritance. (Does it?)</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">The fact that classes and mixins have duplicated functionality, still bugs me.</div><div style="font-size:12.8px" class="">I also prefer "pure" approach, where everything is a struct unless it needs class-only features - deinit, for example. It is my personal opinion.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-02-28 20:28 GMT+03:00 Goffredo Marocchi <span dir="ltr" class=""><<a href="mailto:panajev@gmail.com" target="_blank" class="">panajev@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">So far while pushing for protocol oriented programming as one of Swift's distinctive features, the Swift team (or at least Chris Lattner) stated that inheritance is not a patter which is bad per se, it is a pattern which has its uses and it is fully supported by Swift just as much as other patterns Swift makes available. In my opinion of you have a feature, this feature should not fight with a hand tied behind its back: the "if you do it, do it well" approach :).</div><div class=""><br class=""></div><div class="">Answers like this seem to be the next best thing from asking to remove inheritance outright or to limit it more. Improving protocols, improving functional programming support, etc... all of that is orthogonal to improving OOP through class inheritance. </div><div class="">Support for abstract classes does not force people to use inheritance. Instead of doc using energies pushing down proposals that advocate for improving class based inheritance, I see energy better spent in making proposals that improve protocols unless they get filled by inheritance die hard afraid of the success of protocols meaning a death sentence for inheritance :).</div><div class=""><br class=""><div class="">Sent from my iPhone</div></div><div class=""><div class="h5"><div class=""><br class="">On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">> • What is your evaluation of the proposal?</div><div class="">-1. I would prefer something like mixins that could work without inheritance and would thus also work with value types.</div><div class=""><br class=""></div><div class="">> • Is the problem being addressed significant enough to warrant a change to Swift?</div><div class="">Yes, although I don't think abstract classes that force inheritance and only work for classes is the answer.</div><div class=""><br class=""></div><div class="">> • Does this proposal fit well with the feel and direction of Swift?</div><div class="">No.</div><div class=""><br class=""></div><div class="">> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div class="">My opinion is based on other languages I've used that have better ways to handle this (Ruby, Python, D) as well as the downsides I've seen with abstract classes in Java and C++.<br class=""></div><div class=""><br class=""></div><div class="">> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div class="">I've followed the various threads on this topic that have come up since Swift was open-sourced.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">My GMail keeps breaking threads. I wrote this in reply to this post of Matthew Johnson:<div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html</a><br class=""></div></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-02-28 19:50 GMT+03:00 Антон Жилин <span dir="ltr" class=""><<a href="mailto:antonyzhilin@gmail.com" target="_blank" class="">antonyzhilin@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">It would be interesting to know your opinion on "mixins" proposal. Do you need some kind of "abstract classes for structs", perhaps with multiple inheritance, or you find that more elegant architectual solutions to problems can be found, without partially implemented constructs?<div class=""><a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank" class="">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a><br class=""></div></div>
</blockquote></div><br class=""></div>
</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="">Trent Nadeau</div>
</div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>