[swift-evolution] Closure delegation
Pierre Monod-Broca
pierremonodbroca at gmail.com
Mon Dec 14 02:07:55 CST 2015
I see three solutions which are not exclusive.
var suffix = "suffix"
prepareSomething {
name = self.name + suffix
}
var name = "suffix"
prepareSomething { [suffix = name]
name = self.name + suffix
}
var name = "suffix"
prepareSomething {
it.name = self.name + name
}
or a fourth one where you'd explicitly name `it`, but I’m not sure of the syntax.
Pierre
> Le 11 déc. 2015 à 18:10, ilya <ilya.nikokoshev at gmail.com> a écrit :
>
> I'm still not sure I understand the capture semantics in this proposal. Let's say we want to do stuff inside NSOperation:
>
> class C:NSOperation {
>
> func doStuff() {
>
> // We want to set the name of new operation to be equal the old name + some suffix that is currently bound to 'name'.
> var name = "suffix"
>
> // How we do it right now, assume prepareSomething creates a new NSOperation that we want to configure.
>
> prepareSomething { operation in
> operation.name <http://operation.name/> = self.name <http://self.name/> + name
> }
>
> // How do we do that in the proposal?
>
> prepareSomething {
> name = ?
> }
> }
>
>
> On Fri, Dec 11, 2015 at 3:46 PM, 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/2d3abf76/attachment.html>
More information about the swift-evolution
mailing list