<div dir="ltr">In the proposal, I would recommend stressing how this both subsumes abstract classes and allows similar functionality on value types.<div><br></div><div>I would also recommend adding a more realistic mixin example such as logging, where structs and classes want logging functionality but are not or can't be LoggingObjects. This would show how it gives code reuse without inheritance and how it would be better than abstract classes.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 28, 2016 at 11:43 AM, Антон Жилин <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"><div dir="ltr">I now have 4 votes "for" separating this new entity from protocols. Proposal changed.<div>I tried to solve the aforementioned issues except the last one, which essentially compares mixins to abstract classes.</div><div>More "bug reports" welcome!</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-02-28 16:47 GMT+03:00 Patrick R. Gili <span dir="ltr"><<a href="mailto:gili.patrick.r@gili-labs.com" target="_blank">gili.patrick.r@gili-labs.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I see many problems with this proposal:</div><div><br></div><div>- The proposal doesn't provide a compelling example to change Swift.</div><div><br></div><div>- The proposal doesn't provide much detail. It glosses over the general concept.</div><div><br></div><div>- Protocols define a statement of conformance, not behavior. Adding instance variables and non-default methods is outside the scope of a protocol.</div><div><br></div><div>- However, the proposal does describe something closer to a mix-in. Given my experience with Ruby and mix-ins, I really can't support the notion of mix-ins in Swift. Instance variables defined by a mix-in cause many problems, and hence I don't see this proposal aligned with the direction of Swift.</div><div><br></div><div>-Patrick<br><br><div>Sent from my iPad Pro</div></div><div><div><div><br>On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I agree that adding those features to protocols is simpler. I switched the main suggestion and the alternative.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-27 15:03 GMT+03:00 Haravikk <span dir="ltr"><<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Very interesting alternative!</div><div><br></div><div>I think my preferred implementation is to just add these capabilities to protocols directly, as I guess I just don’t see why we need to introduce a separate mixin type. Providing implementation directly within a protocol is definitely something I’d like in general; while extensions can be a nice way to structure complex protocols and types, sometimes simple cases just don’t really need them IMO, so that’d be nice as a general capability, not just for mixins.</div><br><div><blockquote type="cite"><div><div><div>On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr">Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.<div>So I prepaired a proposal draft to add stored properties to protocols. Here it is:</div><div><a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a><br></div><div><br></div><div>P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".</div></div></div></div>
_______________________________________________<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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>
</div></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>