[swift-evolution] Closure delegation
James Campbell
james at supmenow.com
Fri Dec 11 08:26:11 CST 2015
I think in those cases the compiler would step in and force you to rename
or explicitly reference the bound object i.e "boundObject.boundValue"
On Fri, Dec 11, 2015 at 2:05 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:
> 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?
>
> Btw, this is effectively a variation on Erica Sadun's Method Cascade
> proposal which was filed as a bug report at bugs.swift.org. You might
> want to look into that if you're not already aware of it.
>
> Sent from my iPad
>
> On Dec 11, 2015, at 6:46 AM, Pierre Monod-Broca via swift-evolution <
> 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> 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> wrote:
>
>>
>>
>> On Fri, Dec 11, 2015 at 12:14 PM, James Campbell <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> 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> 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> wrote:
>>>>
>>>>>
>>>>> Le 11 déc. 2015 à 11:54, James Campbell <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> 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
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Wizard
>>>>> james at supmenow.com
>>>>> +44 7523 279 698
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Wizard
>>>> james at supmenow.com
>>>> +44 7523 279 698
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Wizard
>>> james at supmenow.com
>>> +44 7523 279 698
>>>
>>
>>
>>
>> --
>> Wizard
>> james at supmenow.com
>> +44 7523 279 698
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
--
Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/bb247bf6/attachment.html>
More information about the swift-evolution
mailing list