[swift-evolution] Closure delegation
Pierre Monod-Broca
pierremonodbroca at gmail.com
Mon Dec 14 02:03:39 CST 2015
> Le 11 déc. 2015 à 15:05, Matthew Johnson <matthew at anandabits.com> a écrit :
>
> What if the delegate has a member with the same name as a captured value? This would create ambiguity when referring to that name in the closure. Would this just not be allowed and callers required to rename the captured value in the capture list?
I would stay consistent with current @noescape blocks, where the captured value has precedence. Then you would rename with an explicit capture list, or use a different name for your local variables. And in the cases you don’t want to do either, we'd introduce a way to explicitly call delegate’s members. Either a syntax to explicitly name it, à la capture list, or an implicit name, à la `self` (for exemple `it`).
>
> Btw, this is effectively a variation on Erica Sadun's Method Cascade proposal which was filed as a bug report at bugs.swift.org <http://bugs.swift.org/>. You might want to look into that if you're not already aware of it.
Thanks for the note. Yes it raises the same kind of issues, and the use cases overlap. I think they complement one another pretty well.
Method Cascading is a tool for an interface consumer, Closure Delegation is more a tool for an interface provider (then used by the interface's consumers).
Just after the closure returns is a good point to make additional work, like destroying a context setup before the closure call, or taking into account members changed during the closure call. You don’t have that with Method Cascading.
>
> Sent from my iPad
>
> On Dec 11, 2015, at 6:46 AM, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> To answer James:
>> Binding is probably a better word than delegation :), it seems more consistent.
>>
>> I’m ok with the javascript syntax of binding, but the curried-like one has the advantage of being consistent with methods eg:
>> let f = BarImplementation.doStuff // BarImplementation -> () -> ()
>> f(bar)()
>>
>> To answer Marc:
>> The bound value is not captured from the closure definition site, it’s explicitly bound, usually just before calling the closure. I think a strong reference is enough, like when calling a method. Besides the binding wouldn’t mutate the closure, but create a new one, usually short-lived.
>>
>> I think `self` should keep it’s value, and we should find another word for the bound value, especially to avoid `self` being shadowed. I would suggest `this` if it wasn’t heavily used in other language to mean self.
>>
>>
>> Pierre
>>
>>> Le 11 déc. 2015 à 13:36, Marc Knaup <marc at knaup.koeln <mailto:marc at knaup.koeln>> a écrit :
>>>
>>> How would capture semantics work?
>>>
>>> I think this could easily lead to reference cycles as the parameter is captured strongly without any hint at the call-site.
>>> The developer should be warned and have a way to state the capture semantics explicitly through the capture list.
>>>
>>> If the delegate parameter "Bar" becomes "self" in the closure then using "self" everywhere should be required just as in normal closures. "@noescape" would avoid this but the closure reference must be stored then.
>>> If the delegate parameter "Bar" really becomes "self" there's also the problem that the original "self" variable suddenly becomes hidden.
>>>
>>>
>>> On Fri, Dec 11, 2015 at 1:15 PM, James Campbell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>>
>>> On Fri, Dec 11, 2015 at 12:14 PM, James Campbell <james at supmenow.com <mailto:james at supmenow.com>> wrote:
>>> So I don't like this way of declaring it as it is not very clear what it is doing but I actually prefer the javascript way of binding, so in your example the code would be this:
>>>
>>> func prepareSomething(setup:() -> ()) {
>>> let bar = BarImplementation()
>>> // code before
>>> setup().bind(bar)
>>> // code after
>>> }
>>>
>>> The bind method lets Swift know it should bind this to `bar`, so now this is the same as writing `bar`. So in your example:
>>>
>>> without delegation
>>> prepareSomething { delegate in
>>> delegate.someConfig = "Hello World"
>>> }
>>>
>>> with binding
>>> prepareSomething {
>>> someConfig = "Hello World"
>>> }
>>>
>>> These would work the same :)
>>>
>>> On Fri, Dec 11, 2015 at 11:49 AM, Pierre Monod-Broca <pierremonodbroca at gmail.com <mailto:pierremonodbroca at gmail.com>> wrote:
>>> without delegation
>>> prepareSomething { delegate in
>>> delegate.someConfig = "Hello World"
>>> }
>>>
>>> with delegation
>>> prepareSomething {
>>> someConfig = "Hello World"
>>> }
>>>
>>> The exemple is not very compelling, but in a manifest file it would reduce boiler plate.
>>>
>>> Pierre
>>>
>>>> Le 11 déc. 2015 à 12:29, James Campbell <james at supmenow.com <mailto:james at supmenow.com>> a écrit :
>>>>
>>>> Whats the advantage over this ?
>>>>
>>>>> protocol Bar {
>>>>> var someConfig: String { get set }
>>>>> }
>>>>>
>>>>> func prepareSomething(setup: (delegate: Bar) -> ()) {
>>>>
>>>>
>>>> On Fri, Dec 11, 2015 at 11:27 AM, Pierre Monod-Broca <pierremonodbroca at gmail.com <mailto:pierremonodbroca at gmail.com>> wrote:
>>>>
>>>>> Le 11 déc. 2015 à 11:54, James Campbell <james at supmenow.com <mailto:james at supmenow.com>> a écrit :
>>>>>
>>>>> Could you explain a little more its a bit confusing ?
>>>>>
>>>>> On Fri, Dec 11, 2015 at 10:32 AM, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> A groovy closure can have a delegate which replaces `this` as the default receiver. The issue in groovy is that it is not compatible with static compilation, and there is no way to know from the code what is the type of the delegate.
>>>>>
>>>>> It works great for DSL. It would work great the Swift Package Manager manifest, among other things.
>>>>>
>>>>> It could look like this in swift
>>>>>
>>>>> protocol Bar {
>>>>> var someConfig: String { get set }
>>>>> }
>>>>>
>>>>> func prepareSomething(setup: @delegate Bar -> () -> ()) {
>>>> Here we define a function `prepareSomething(_:)` which receives one parameter: a closure that takes a delegate conforming to `Bar`, and otherwise take no parameter and returns nothing
>>>>
>>>>> let bar = BarImplementation()
>>>>> // code before
>>>>> setup(bar)()
>>>> Here we pass a delegate to the closure, then call the closure
>>>>
>>>>> // code after
>>>>> }
>>>>>
>>>>> prepareSomething { () -> () in
>>>> Here we call the function `prepareSomething(_:)` with a closure which we define a the same time
>>>>
>>>>> someConfig = "Hello world"
>>>> Here `someConfig` is a property of the closure’s delegate
>>>>
>>>>> }
>>>>>
>>>>> Where `someConfig` would refer to bar.
>>>>>
>>>>
>>>> I’m not sure about the syntax, we could also declare the delegate that way, maybe :
>>>> func prepareSomething(doSomething: @delegate(Bar) () -> ()) {
>>>> /**/
>>>> }
>>>>
>>>>> Pierre
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Wizard
>>>>> james at supmenow.com <mailto:james at supmenow.com>
>>>>> +44 7523 279 698 <tel:%2B44%207523%20279%20698>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Wizard
>>>> james at supmenow.com <mailto:james at supmenow.com>
>>>> +44 7523 279 698 <tel:%2B44%207523%20279%20698>
>>>
>>>
>>>
>>> --
>>> Wizard
>>> james at supmenow.com <mailto:james at supmenow.com>
>>> +44 7523 279 698 <tel:%2B44%207523%20279%20698>
>>>
>>>
>>>
>>> --
>>> Wizard
>>> james at supmenow.com <mailto:james at supmenow.com>
>>> +44 7523 279 698 <tel:%2B44%207523%20279%20698>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/32e034ce/attachment.html>
More information about the swift-evolution
mailing list