<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Before further work on the details of the design, I urge you to focus on the problem to be solved by the proposed changes. I felt strongly that the abstract classes proposal also foundered on this crucial point (<a href="https://jeremywsherman.com/blog/2016/02/29/review-se-0026-abstract-classes-and-methods/">https://jeremywsherman.com/blog/2016/02/29/review-se-0026-abstract-classes-and-methods/</a>).</div><div><br></div><div>Currently the primary motivation is "fixing drawbacks of abstract classes". But Swift does not have abstract classes (yet - review is pending), so it does not have any of their drawbacks. This leaves a motivation vacuum.</div><div><br></div><div>Mixins have a long (and confused - the early Lisp implementations appear to have been misunderstood, see <a href="http://www.dreamsongs.com/Files/Incommensurability.pdf">http://www.dreamsongs.com/Files/Incommensurability.pdf</a>) history. There are plenty of languages now that include them or variations on them. The current proposal does not take advantage of this rich living resource to feature problems solved (and new problems created) by mixins, nor does it situate the design relative to prior art / related literature (choose the more significant term depending on your exposure to either IP law or conference proceedings ;).</div><div><br></div><div>When it comes of Lisp mixins (flavors), their runtime behavior was more like the advice features of aspect-oriented programming systems, with code executing before, after, or around a primary method. (The actual way mixin functionality was composed with a primary method was programmer controllable, and CLOS provided several standard combinations out of the box.)</div><div><br></div><div>The high-level gist is that mixins sought to provide declarative composition of behavior - "it's this, with a hint of this, and some of that tossed in to spice up the basic behavior" - vs the procedural composition afforded by inheritance - "and now super.doSomething, just like any other procedure call". willSet/didSet bear some resemblance to before/after mixins, but are currently rather limited in applicability.</div><div><br></div><div>What could we accomplish with before advice on viewDidLoad? Would this solve any thorny problems we have now? Might adding aspect oriented programming features to protocols avoid the sticky issue of stored properties while neatly solving real problems?</div><div><br></div><div>I don't know the answers, but feel a convincing proposal will speak to how it will solve problems, while a truly wondrous proposal will relieve me of burthens I didn't even know I had been shouldering all this time.</div><div><div>--<div>Jeremy W. Sherman</div><div><a href="http://jeremywsherman.com/">http://jeremywsherman.com/</a></div></div></div><div><br>El 29-02-2016, a las 13:51, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escribió:<br><br></div><blockquote type="cite"><div><div dir="ltr">I'm prepairing to create a pull request, so I moved the proposal from Gist to my fork of swift-evolution.<div>Link to the proposal new and hopefully final home:</div><div><a href="https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md">https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md</a><br></div><div><br></div><div>Should I create a pull request right now or wait a bit?</div><div><br><div>Some details need to be discussed:</div><div><br></div><div>1. Do mixins need associated types? Would generics be more appropriate to them?</div><div><br></div><div>2. `mixin` vs `mixin protocol`. On one hand, `mixin protocol` does not require a keyword.</div><div>On the other hand, as stated in a special section, mixins cannot be used everywhere a protocol can. Protocols, mixins, traits, interfaces are all different entities.</div></div><div><br></div><div>3. `mixin` vs `trait`. Please read Wiki or any other source and tell what is a better name.</div><div><br></div><div>4. Objective-C interfacing. Do we have to require it now? (I doubt so.) Can we allow mixing-in Swift mixins to Objective-C classes?</div><div><br></div><div>5. Are you happy with Initializers section?</div><div><br></div><div>6. Can motivation examples be improved?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-29 4:07 GMT+03:00 Step C <span dir="ltr"><<a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.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>Sorry, I understood "that phrase" to mean what I just stated. <br><br></div><div><div class="h5"><div><br>On Feb 28, 2016, at 8:03 PM, Step C <<a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>I understood him to mean that abstract classes cannot be used for value types, but it would be natural to want that functionality. Mixins would provide that capability for value types as well as classes.<br></div><div><br>On Feb 28, 2016, at 7:41 PM, Trent Nadeau <<a href="mailto:tanadeau@gmail.com" target="_blank">tanadeau@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">The quoted portion of the proposal below doesn't make any sense to me. Subclasses can't be value types. Do you mean the structs could have similar functionality?<div><br></div><div><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px">Firstly, only classes can inherit from such abstract classes, while it can be easily seen that some subclasses of</span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;color:rgb(51,51,51);background-color:rgba(0,0,0,0.0392157)">CachingSerializable</code><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px"> or </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;color:rgb(51,51,51);background-color:rgba(0,0,0,0.0392157)">SignalSender</code><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px"> would naturally have value semantics (be structs, in other words).</span><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 28, 2016 at 5:03 PM, Антон Жилин <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"><div>Link to the proposal: <a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-29 0:56 GMT+03:00 Step C <span dir="ltr"><<a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would be helpful if you include the new draft. Or at least a link to it.<br>
<span><br>
> On Feb 28, 2016, at 3:30 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I have rewritten almost the whole proposal in the last 10 hours. I encourage everyone interested to reread it and suggest fixes, improvements, as well as new directions for discussion.<br>
</span><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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</div></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Trent Nadeau</div>
</div>
</div></blockquote></div></blockquote></div></div></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">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>