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

[Mike Kluev]

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

>
> If that’s the case then this wouldn’t solve one of the major use cases I
> listed for this: splitting up cross-platform classes into platform-specific
> files. The idea is that each target contains a different subset of the
> files. Consider a case where two platforms are similar enough to share some
> code but not all code. For instance:
>
>
i think we need a better real-world example, as in this one it's probably
easier to have "View" defined as a type alias to either UIView or NSView
depending upon a platform and similarly define currentGraphicsContext() to
be either UIGraphicsGetCurrentContext() or
NSGraphicsContext.currentContext()?.CGContext depending upon a platform and
have a single code base afterwords:

class PresentationView: View {

    private func draw(inContext context: CGContext) {

        // Shared CoreGraphics drawing

    }



    func draw(_ rect: CGRect) {

        self.draw(inContext: currentGraphicsContext())

    }

}


having said that, yes, i can see your point. my fear is that it will be (1)
too fragile (e.g. you have "TableViewDelegate" in the ledger and just
forgot to include the relevant file in the target - the app compiles but
then misbehaves, and (2) open for abuse.


alternative 1 - it's not too hard to put an empty:


part Feature of SomeClass {}


for the relevant platform


alternative 2 - have this in the ledger:


class Some {

    part Feature1

    optional part Feature2

}


as an "opt-in" to the behaviour you want.


i think this type of refinement can be done at some later stage. after all,
we do not have even (much needed IMHO) optional protocol methods without
resorting to @objc as of now...


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