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

Mike Kluev mike.kluev at gmail.com
Wed Nov 8 08:45:01 CST 2017


On 8 November 2017 at 14:20, Mike Kluev <mike.kluev at gmail.com> wrote:

> On 8 November 2017 at 10:54, Benjamin G <benjamin.garrigues at gmail.com>
> wrote:
>
>> All your use cases make perfect sense, however i see one potential issue
>> with this "pattern" :
>>
>> I've seen a LOT of iOS developers (some juniors, some not) ending up with
>> monstruous UIViewControllers, and it has happened almost since the very
>> beginning of iOS development. Because of their lack of understanding of the
>> MVC pattern, they completely under estimate either the model or the view
>> layer and put too many things in their VC.
>>
>> Now this pattern would give them the illusion that they're working in a
>> sane architecture and that they've decomposed the problem correctly, but in
>> fact were not. The fact that extension wouldn't let you add variable makes
>> it harder to conceal the problem, but with "continuations" i can see no
>> limit.
>>
>> What do you think ?
>>
>>
> good tools won't fix bad developers (c)
>
> you know that you can already sort of "store variables" in extensions,
> right? obj-c associated object is one way (1). and if we are talking about
> the use case of extending "your own types only" -- i am -- your own classes
> are under your full control, so nobody stops you from having, say, an
> "extensionVars" dictionary in your root class(es) and a handy set of
> generic api's to get/set those in a convenient manner without too much
> effort (2). is it ideal? no. performance suffers. usability suffers. non
> trivial to have weak/unowned variables with (2). not a "first class
> citizen" solution. the sheer number of hits of "how to i store variables in
> extensions in swift" (more than a million now) hints you that the language
> can step in to help, at least in the critical use case of "own types".
>
>
ftm, this is what i have now (based on method 2):

extension SomeClass /* FeatureX */ {



    var someVar: Float {

        get { return extensionVar() }

        set { setExtensionVar(newValue) }

    }



    var otherVar: Bool {

        get { return extensionVar() }

        set { setExtensionVar(newValue) }

    }



    var someOptionalVar: Int? {

        get { return extensionVarOpt() }

        set { setExtensionVarOpt(newValue) }

    }



    func initFeatureX() {

        // init is optional if you can trust your code doing "set" before
the first "get"

        someVar = 0

        otherVar = false

    }

}


this is on the use side. "not too bad". not too insane syntax. not too much
code on the use side. note that i don't even have to spell the keys
explicitly, so it is the same copy-paste code for all the variables. but
then... optional vars need a different syntax. no weak/unowned support.
non-optional ones need to be "set before get". performance suffers. etc,
etc... (see the above).


this is the ideal i am dreaming of:


part FeatureX SomeClass {

    var someOptionalVar: Int? {

        var someVar: Float = 0

        var otherVar: Bool = false

        var someOptionalVar: Int?



        weak var someWeakVar: X?

    }

}

parts (continuations) can be an answer.

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


More information about the swift-evolution mailing list