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

[Benjamin G]

I'm extremely curious to know the use case that made you code this way. Is
it one of the case Adam listed before ?

I don't want to sidetrack this issue, but i wonder if something like this
https://golang.org/doc/effective_go.html#embedding wouldn't be a "cleaner"
solution.

On Wed, Nov 8, 2017 at 3:45 PM, Mike Kluev <mike.kluev at gmail.com> wrote:

> 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/a38f8054/attachment.html>