[swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp]

> On Nov 3, 2017, at 10:55 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
> 
> On 3 November 2017 at 17:23, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
> 
> 
> 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.
> 
> 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.

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.

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.

Out of the strategies I’ve seen used for cross-platform code this one was the most frustrating to work with in my experience.

> My argument is that there should be no ledger in the first place. IMO you haven’t made the case for that requirement.
> 
> If you forget to implement a protocol then ...
> 
> i mean this:
> 
> class MyView: UIView {
>     optional part Drawing
> }
> 
> part Drawing of MyView { // **** forgot to include this into target
>     override func drawRect(...) {
>         .....
>     }
> }
> 
> the app compiles but doesn't work correctly.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/1ec017c2/attachment.html>