<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">+1 (but <b>see below</b>)</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Example:</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<blockquote><div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">My custom Swift notification system currently has two problems that would be solved by mixins:</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">1. Anyone conforming to StdEmitterType has to provide “public var _listeners = EventStorage()", which is obvious non-ideal (I have an Xcode snippet for that).</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">2. I have EmitterType protocol that defines the publish/subscribe contract, and StdEmitterType protocol that provides a standard implementation of the publish/subscribe methods using a stored _listeners property (provided by the conforming class/struct as described in #1). The distinction between EmitterType and StdEmitterType is confusing when both are called protocols, because StdEmitterType is really a mixin. Calling EmitterType a protocol and StdEmitterType a mixin would clear up the confusion.</span></span></span><i><br></i></div>
</blockquote><div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Because of reason #2, I'm strongly in support of using a separate keyword.</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"><b>I do feel</b>, however, that maybe this isn't a single problem, but instead <b>two orthogonal problems</b> that could have separate solutions:</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">1) <b>Go-style embedding</b>, where a struct's members become the members of its containing struct/class</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">2) an <b>“implicit delegate”</b> facility that allows a struct (you may call it a “mixin”) to access the self of its container, and to impose requirements on the container (funcs/vars that the container has to implement)</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">#1 is useful without #2 — the logging example doesn't need anything from it container, it just wants to add a variable</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">#2 is useful without #1 — I have other mixin-like examples that benefit from being included (a) in multiple copies, and/or (b) non-anonymously (with a meaningful name), and/or (c) privately.</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"><b>Examples of #2 without #1:</b></span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">— I have an activity system in my app that tracks the progress and completion of a tree of long-running operations (think a Make-like build process, or an IDE-style code analysis consisting of multiple steps operating on multiple files). The relevant state management and notification logic is encapsulated as ProcessorImpl mixin-like class that tightly binds to its host via an initialization method:</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public func initializeWithHost&lt;Host: EmitterType&gt;(host: Host, performs performMethod: (Host) -&gt; (Request, OperationContext) -&gt; Promise&lt;Void&gt;)</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">&nbsp;&nbsp;&nbsp;...some classes perform multiple kinds of processing, so they end up creating multiple ProcessorImpl's; and even for those classes that use only one instance, it is helpful to give it a name (private let analysisState = ProcessorImpl()) and to keep it private (it is manually published via a separate property that has a protocol type)</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">— my current Delayed class that implements something similar to performSelector:afterDelay: / cancelPerformSelector in Objective-C, or to function throttling/unbouncing in JavaScript. It has to be a class, because it contains mutable state that is modified from within dispatch_async. Would be great for it to instead be a mixin that would use the “self” of its container, without creating a separate object.</span></span></span><br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;">&nbsp;</div>
<div style="font-family:Arial;"><span class="colour" style="color:rgb(0, 0, 0)"><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Thoughts?</span></span></span><br></div>
</body>
</html>