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

[Mike Kluev]

On 3 November 2017 at 18:08, Adam Kemp <adam_kemp at apple.com> wrote:

>
> 1. You end up with a whole section of type aliases at the top of the file,
>

i'm putting those in a separate Platform.swift file


> and as you read the file it’s hard to understand what those types actually
> represent.
>

in the example above "View" - a very similar concept between macOS and
iOS/tvOS/watchOS.
in case of doubts - command click is always at the finger tips.


> Which methods are you actually allowed to use? What should code completion
> show you?
>

autocomplete shows the relevant methods on each platform correctly.

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.
>

if the differences are minute i'm creating my own extension methods to make
the difference non existent.

example: layer is optional on OSX and non optional on iOS. the difference
is minute and i can make this difference non existent, e.g. by:

extension UIView {

    var viewLayer: CALayer? {

        return layer

    }

}

and a similar thing on OSX, and afterwards i have single API on both
platforms with no differences.

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.
>

>

i rarely have to use conditional compilation and even when have to do so i
normally hide it inside the relevant "utility" extensions, from then on i
don't see anything "conditional" within the normal app sources.


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

quite the contrary to me - the best possible experience with such an
approach (during many years of experience ftm)


> My argument is that there should be no ledger in the first place. IMO you
>> haven’t made the case for that requirement.
>>
> the real-world example would be:

case 1. you have a single page of paper on hands saying: "partial contract
A. continued elsewhere. Blah, blah". you look around and within a multitude
of papers on the table you managed to find another sheet of paper with
"partial contract A. continued elsewhere. Blah, blah". in order to find the
whole thing you will have to look in all papers on your table, then in the
shelve and then in the whole building (module boundaries)

case 2. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around and within a
multitude of papers on the table you managed to find another sheet of paper
with: "part B of contract A, blah, blah". at that point you know that you
found everything, don't need to look on the shelve or in the whole building.

case 3. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around the whole
building and found no "part B". at this point you know - something is lost,
and act accordingly.

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.
>

i don't see why (and I am not talking about cross platform code at this
point). i have instances like these implemented via extensions in a day to
day code. the split of the class into files was done merely for organising
purposes, to keep file size manageable.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/277b0a1c/attachment.html>