<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Nov 2016, at 04:37, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">I think you are fixating on my talk about imp caching instead of my main point about setting up the state of my delegator to avoid unneeded work when a registered delegate hasn't implement a delegation point. It an unrelated topic to what is being discussed.<br class=""><br class="">-Shawn</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Nov 15, 2016 at 5:27 PM Karl <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 15 Nov 2016, at 19:38, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="gmail_msg" target="_blank">shawnce@gmail.com</a>> wrote:</div><br class="m_6020228533155189530Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="white-space:pre-wrap" class="gmail_msg">Using sub-protocols may be sufficient and make sense... to be honest I haven't had the time to fully explore this space and convert some things I have done in objective-c to pure swift. I do wonder how often that those sub-protocols would degenerate into having single methods.<br class="gmail_msg"><br class="gmail_msg">In a nut shell it isn't atypical for a delegate to only care about "injecting itself" (e.g. implementing a delegate function) for a subset of the available delegation points leaving the others unimplemented. In the objective-c case the delegator can evaluate what delegation points a delegate implements at time of delegate registration (or more dynamically ... however I often did imp caching for performance reasons in some of my designs). This probe on delegate registration may make sense for the delegator if additional bookkeeping, processing, state management, or potentially whole code path/objects can be avoided if the delegate doesn't implement a delegation point(s). If the delegation points happened to be implemented using a default nop implementation this type of optimization may not be possible.<br class="gmail_msg"><br class="gmail_msg">In a nutshell I see and have the need for the delegator to know if the delegate has actually provided an implementation of their own or not so I can potentially leverage optimizations internal to my delegator. As a delegate is also nice to know clearly what I have to implement or not and the optional protocol member concept is one way of doing that, it would be nice to have something like that to help delegate implementors.<br class="gmail_msg"><br class="gmail_msg">I suggest mentally evaluating the delegation points of URLSession with the perspective of the delegator (URLSession) being able to optimize what it does based what it delegate has provided and implementation for. For example the new metrics delegation point like could optimize away book keeping and related processing if the delegate isn't interested. Additionally look at it from the point of view of a delegate implementor noting the despite already having some number of sub-protocols you still often only implement one or two delegate points. Alternate swifty implementations likely exist that would be interesting to explore to help inform what makes sense as a language addition and/or help folks used to "traditional" delegation pattern under Objective-C follow more Swifty patterns going forward.<br class="gmail_msg"><br class="gmail_msg">-Shawn</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Nov 15, 2016 at 9:24 AM Karl <<a href="mailto:razielim@gmail.com" class="gmail_msg" target="_blank">razielim@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 15 Nov 2016, at 16:46, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="gmail_msg" target="_blank">shawnce@gmail.com</a>> wrote:</div><br class="gmail_msg m_6020228533155189530m_8893734347893288728Apple-interchange-newline"><div class="gmail_msg">This has been discussed somewhat heavily in the past and nothing yet has really moved forward on it. I do think a good way of doing something like this would be helpful. I have resulted to defining an interface with an extension that provides empty defaults and for each function a match bool var exists to imply if it exists or not. The code accepting a delegate can probe these bool vars to configure itself to efficiently operate based on knowledge about what the delegate expects (some missing from most proposed solutions other then @objc optional).<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-interchange-newline"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg">One major example is the NS/UITableViewDataSource or Delegate - there are many many methods that you don't need to implement, hence are optional.<br class="gmail_msg"><br class="gmail_msg">But I think that this was partially solved by default implementation of protocol methods, which pretty much does what you want...<br class="gmail_msg"></blockquote><br class="gmail_msg">I just realized I only responded to someone else, and not the whole list. It does, but it forces me to make the return value of the protocol method optional, so that the default implementation can return nil. <br class="gmail_msg"><br class="gmail_msg">In the end, I guess that's not so bad, since I'm not happy with the entire approach, but it'll do for now.<br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"><div class="gmail_msg">What's different about having the method return nil vs being optional? You're attempting to call it either way, and presumably need some means of handling the return value, except in Swift it's all nice and explicit and easy to put in a conditional like:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>if let result = myObject.someOptionalMethod() { /* Do some stuff */ }</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>print(myObject.someOptionalStringMethod() ?? "")</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><br class="gmail_msg"></font></div>And so-on. If you need a method to be both optional, and return a nilable result then you can use a double optional like so:<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>if let result = myObject.someDoubleOptionalMethod() { // Method was implemented</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>if let value = result { // Method returned a value</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>/* Do some stuff */</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>}</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><span class="gmail_msg m_6020228533155189530m_8893734347893288728m_1374670648404452039Apple-tab-span" style="white-space:pre-wrap"> </span>}</font><br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">By defining the methods as returning an Optional and throwing in default implementations you can specify fewer, bigger protocols and make clear what the requirements really are, though personally given the choice I'd prefer a dozen smaller protocols that are absolutely explicit in what they do.</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But yeah, I think the tools you need are all there already; maybe there's an argument to be made for allowing default return values on protocol methods, to reduce the boiler-plate?</div></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I think there is a difference between:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- A method which returns an optional result, and</div><div class="gmail_msg">- An optional method which, if present, always returns a result</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Perhaps not so much of a difference at the usage site (it’s just a question of placing a ? for optional chaining), but semantically and when conforming to the protocol, they mean different things.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Karl</div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">If you don’t mind me asking, what is your use-case?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Even though I think "optional methods" and “methods returning optionals” are different things, I don’t really have any examples where optional methods are better than sub-protocols.</div><br class="gmail_msg"><div class="gmail_msg">e.g.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```</div><div class="gmail_msg">// Core callbacks</div><div class="gmail_msg">protocol MyDelegate { }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">// Optional callbacks, added like a mixin</div><div class="gmail_msg">protocol MyDelegateWithExtras : MyDelegate { }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">// Some more optional callbacks</div><div class="gmail_msg">protocol MySubDelegate : MyDelegate {}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">class DelegateImpl : MySubDelegate, MyDelegateWithExtras {</div><div class="gmail_msg"> // Implement all core + optional callbacks</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">var d : MyDelegate = DelegateImpl()</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">if let extras = d as? MyDelegateWithExtras {</div><div class="gmail_msg"> // invoke optional functionality</div><div class="gmail_msg">}</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I don’t know what the overhead of the as? call is, but it’s almost certainly less than an Obj-C `respondsToSelector` call. Depending on whether you need to swap the delegate for objects of different types, you could also use generics to optimise the checks (and possibly more) away.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Karl</div></div></blockquote></div>
</div></blockquote><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">You sometimes needed those kind of caching techniques in Objective-C, because it’s such a dynamic language. The question of “does this object respond to this selector” has many complex considerations. For one thing, objects may add and remove methods (or have it done to them) at any time. Objects can even synthesise implementations the first time they receive a selector. It’s been optimised massively over the years, but it can still be a pretty slow operation -- and since hardly anything actually makes use of those features it’s common to ask once and cache the responses in a bitmask. In Objective-C, asking whether or not an object conforms to a protocol just cascades in to a bunch of calls to “respondsToSelector”, so it’s also very painful.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The Swift runtime doesn’t have those dynamic features. If you added any methods to a bridged Swift object via the Obj-C runtime, those methods wouldn’t be callable from your Swift code anyway, so we never have to worry about that. Protocols in Swift are not the loose contracts of Objective-C; you can create empty “marker” protocols and different objects may or may not conform to it, even though it has no functional requirements. That means testing for conformance should be much faster, too (and covers all requirements at once).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Protocol dispatch in Swift is fast, there is something called a “protocol witness table” (vtable + pointer + lifetime func ptrs), which is what is actually getting stored when you declare a variable with only a protocol for a type. So there isn’t really a huge runtime cost from the dispatch anymore either, and you don’t need to explicitly resolve and store the IMPs yourself to get decent performance.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Karl</div></div></blockquote></div>
</div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">It’s the same point. I’ll try to make it more obvious: put your optional stuff in a sub-protocol and check for conformance to the sub-protocol. It’ll be fast and you don’t need any of the caching you do with Objective-C.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">(delegate as? SpecialSubDelegate)?.extraCallback() </font></div></blockquote><div class=""><br class=""></div><div class="">Should be as fast as whatever you were doing in Objective-C before. If you have larger blocks of potentially-avoidable work to do, wrap the delegate cast in an “if let” and do it there.</div><div class=""><br class=""></div><div class="">For example:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">protocol ScrollViewDelegate : class {}</font></div><div class=""><font face="Menlo" class="">protocol ScrollObserver : ScrollViewDelegate {</font></div><div class=""><font face="Menlo" class=""> func scrollViewDidScroll(_ scrollview: UIScrollView)</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class="">protocol ScrollToTopController : ScrollViewDelegate {</font></div><div class=""><font face="Menlo" class=""> func scrollViewShouldScrollToTop(_ scrollview: UIScrollView) -> Bool</font></div><div class=""><span style="font-family: Menlo;" class=""> func scrollViewDidScrollToTop(_ scrollview: UIScrollView)</span></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">Then, in your scrollview code, you’d declare your delegate as:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">weak delegate : ScrollViewDelegate</font></div></blockquote><div class=""><br class=""></div><div class="">and when you want to use the optional methods, as described earlier:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">(delegate as? ScrollObserver)?.scrollViewDidScroll(self)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div></blockquote>or if you have more work to do:<br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">if let controller = delegate as? ScrollToTopController,</font></div><div class=""><font face="Menlo" class=""> controller.scrollViewShouldScrollToTop(self) {</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> // Perform the scroll</font></div><div class=""><font face="Menlo" class=""> controller.scrollViewDidScrollToTop(self)</font></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>