<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 10:55 AM, Mike Kluev <<a href="mailto:mike.kluev@gmail.com" class="">mike.kluev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On 3 November 2017 at 17:23, Adam Kemp <span dir="ltr" class=""><<a href="mailto:adam_kemp@apple.com" target="_blank" class="">adam_kemp@apple.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><span class=""><div class=""><br class=""></div></span><div class="">When you actually try to use that technique in a fuller example it becomes impractical. I know because some people working on the same code base tried that, and it was much worse. </div></div></div></blockquote><div class=""><br class=""></div><div class="">please provide more details on this. i was and still using such a technique, so want to be prepared for those pitfalls before i actually encounter them.</div></div></div></div></div></blockquote><div><br class=""></div><div>1. You end up with a whole section of type aliases at the top of the file, and as you read the file it’s hard to understand what those types actually represent. Which methods are you actually allowed to use? What should code completion show you? Nothing is as it seems.</div><div><br class=""></div><div>2. The type alias is only useful when the naming of the methods/properties is identical and the sequence of calls you have to make is identical, which very often isn’t the case. You end up needing conditional compilation anyway for cases where you only need to make a call on one platform, or where the method you have to call is named slightly different or takes different arguments.</div><div><br class=""></div><div>Out of the strategies I’ve seen used for cross-platform code this one was the most frustrating to work with in my experience.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">My argument is that there should be no ledger in the first place. IMO you haven’t made the case for that requirement.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><br class=""></div><div class="">If you forget to implement a protocol then ...</div></div></div></blockquote><div class=""><br class=""></div><div class="">i mean this:</div><div class=""><br class=""></div><div class="">class MyView: UIView {</div><div class=""> optional part Drawing</div><div class="">}</div><div class=""><br class=""></div><div class="">part Drawing of MyView { // **** forgot to include this into target</div><div class=""> override func drawRect(...) {</div><div class=""> .....</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">the app compiles but doesn't work correctly.</div></div></div></div></blockquote><div><br class=""></div><div>That example doesn’t make any sense. You wouldn’t override a drawRect function in the shared file because that function is overriding a platform-specific function. This is exactly the use case I gave an example for. What you would do instead is override the platform-specific draw function in a platform-specific file and then redirect to a shared implementation that has a cross-platform interface.</div><div><br class=""></div><div>In general I would say you shouldn’t implement a protocol method for a protocol not declared in the same file or override a method of a superclass not explicitly mentioned in that file. That’s just a bad practice. Instead you would put that function in the same file as the protocol or superclass is mentioned and then, if needed, redirect to another function in another file. Then if you leave out that file it won’t compile because you’ll be missing a function.</div><div><br class=""></div><div>Trust me, this works very well in practice. I never once ran into a bug like that over several years of doing things this way.</div></div></body></html>