<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>While delegates and callbacks have their place I think inheritance has its place as well. The former are inherently dynamic (pluggable) even if my design might be static and not allow plugging in different functionality at runtime. In addition the delegate needs memory in the base class which is not the case with inheritance.</div><div><br></div><div>Regarding testability: if we had real multiple inheritance then testing would be as easy as you can put the logic in its own class instead of a subclass and create the subclass by inheriting from the base class and the logic class. That means you can test the logic class in isolation just like you can do with delegates. Combining functionality like this is called the cake pattern in Scaka.</div><div><br></div><div>-Thorsten </div><div><br>Am 02.03.2016 um 06:24 schrieb Simon Pilkington via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Increasingly I am finding that in almost all cases composition provides a better alternative to inheritance. In the case of sharable logic, that logic is better provided as its own complete class with something like the delegate pattern or callbacks if extensibility is required. This encourages small classes with limited responsibility that can be easily/independently tested. <div class=""><br class=""></div><div class="">So with that in mind, the problem I see with this proposal is that it introduces syntactical and conceptual complexity to the language - in particular providing a mechanism to resolve cases of the diamond problem, ordering of init/deinit etc is going to make the usage non-trival - without having a substantive benefit outside of what can be achieved more robustly with the existing constructs - such as protocols - the language provides.</div><div class=""><br class=""></div><div class="">For the examples for mixins presented so far, I’d be interested in understanding why they couldn’t be solved with the existing language and design patterns.</div><div class=""><br class=""></div><div class="">-Simon</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 1 Mar 2016, at 8:15 PM, Andrey Tarantsov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">+1 (but <b class="">see below</b>)</span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Example:</span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<blockquote class=""><div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""><br class=""></i></div>
</blockquote><div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"><b class="">I do feel</b>, however, that maybe this isn't a single problem, but instead <b class="">two orthogonal problems</b> that could have separate solutions:</span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">1) <b class="">Go-style embedding</b>, where a struct's members become the members of its containing struct/class</span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">2) an <b class="">“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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"><b class="">Examples of #2 without #1:</b></span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"> public func initializeWithHost<Host: EmitterType>(host: Host, performs performMethod: (Host) -> (Request, OperationContext) -> Promise<Void>)</span></span></span><br class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"> ...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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><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 class=""></div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""> </div>
<div style="font-family:Arial;" class=""><span class="colour" style=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Thoughts?</span></span></span><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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>