How do you import the API to Swift when the target and action properties are separate?
Félix
···
Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so :
addAction(myClass.actionFunction)
Instead of what it does now:
addAction(myClass, action:"actionFunction:")
Sent from my iPhone
On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mailing@xenonium.com> wrote:
Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
These are very good points.
Actually, it comes in as addAction(action: Selector), not String. You can initialize a Selector from a string literal.
Yes :) should have looked it up before I tried to remember it off the top of my head.
Three questions about your proposal:
1. Where does "AnyObject -> Void" come from? The only signature information in a selector is the (minimum) number of arguments. Those arguments can be of any type, and
Well I would want to know what selectors people would us:
One with one argument tend to be for events like button actions and notifications which could be replaced by closures. We could deprecate or provide warnings when trying to use the Selector Apis in swift.
Others with more tend to be for canPerformSelector which is replaced by optionals.
The one edge case not handled is nsinvocation or performSelector, I would be interested why people use this use case and how we would replace it in swift (if at all).
2. How are we supposed to implement this? You need to somehow convert a closure (a pointer to a bunch of captured variables with a pointer to a function embedded inside it) into a selector (a pointer to a table of selectors inside the Objective-C runtime, which does not do any normal memory management); I just don't see how you make that work. Saying "let's do this thing" doesn't mean it's *possible* to do the thing.
I get that they are different but I had the idea that the compiler could generate a unique name for each closure which when referenced by a selector it would invoke.
But this would be irrelevant if we moved towards closure Apis.
3. What about other uses for selectors? addAction() is all well and good, but you also need removeAction(), and Swift closures don't have stable identities to test with.
I question when we use things such as removeAction? I've only used addAction. But I guess again if we moved to closure Apis this point would be moot.
To me the only case that needs selectors is performSelector or Nsinvocation. The others can be replaced by closures and the selector api to be deprecated or to show a warning in swift :) (Xcode could even help migrate by moving it to a closure that calls the function the selector was pointing to)
I'm not a compiler expert so I rely on the swift team to tell me what's possible (although at this early stage I think it's more important to figure out what we want and not be bound by what's possible right now)
How would the closure based API work with Interface Builder ?
Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so :
addAction(myClass.actionFunction)
Instead of what it does now:
addAction(myClass, action:"actionFunction:")
···
Sent from my iPhone
On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mailing@xenonium.com> wrote:
Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
These are very good points.
Actually, it comes in as addAction(action: Selector), not String. You can initialize a Selector from a string literal.
Yes :) should have looked it up before I tried to remember it off the top of my head.
Three questions about your proposal:
1. Where does "AnyObject -> Void" come from? The only signature information in a selector is the (minimum) number of arguments. Those arguments can be of any type, and
Well I would want to know what selectors people would us:
One with one argument tend to be for events like button actions and notifications which could be replaced by closures. We could deprecate or provide warnings when trying to use the Selector Apis in swift.
Others with more tend to be for canPerformSelector which is replaced by optionals.
The one edge case not handled is nsinvocation or performSelector, I would be interested why people use this use case and how we would replace it in swift (if at all).
2. How are we supposed to implement this? You need to somehow convert a closure (a pointer to a bunch of captured variables with a pointer to a function embedded inside it) into a selector (a pointer to a table of selectors inside the Objective-C runtime, which does not do any normal memory management); I just don't see how you make that work. Saying "let's do this thing" doesn't mean it's *possible* to do the thing.
I get that they are different but I had the idea that the compiler could generate a unique name for each closure which when referenced by a selector it would invoke.
But this would be irrelevant if we moved towards closure Apis.
3. What about other uses for selectors? addAction() is all well and good, but you also need removeAction(), and Swift closures don't have stable identities to test with.
I question when we use things such as removeAction? I've only used addAction. But I guess again if we moved to closure Apis this point would be moot.
To me the only case that needs selectors is performSelector or Nsinvocation. The others can be replaced by closures and the selector api to be deprecated or to show a warning in swift :) (Xcode could even help migrate by moving it to a closure that calls the function the selector was pointing to)
I'm not a compiler expert so I rely on the swift team to tell me what's possible (although at this early stage I think it's more important to figure out what we want and not be bound by what's possible right now)
How would the closure based API work with Interface Builder ?
On 30 Dec 2015, at 15:48, Félix Cloutier <felixcca@yahoo.ca> wrote:
How do you import the API to Swift when the target and action properties are separate?
Félix
Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so :
addAction(myClass.actionFunction)
Instead of what it does now:
addAction(myClass, action:"actionFunction:")
Sent from my iPhone
On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mailing@xenonium.com> wrote:
Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
These are very good points.
Actually, it comes in as addAction(action: Selector), not String. You can initialize a Selector from a string literal.
Yes :) should have looked it up before I tried to remember it off the top of my head.
Three questions about your proposal:
1. Where does "AnyObject -> Void" come from? The only signature information in a selector is the (minimum) number of arguments. Those arguments can be of any type, and
Well I would want to know what selectors people would us:
One with one argument tend to be for events like button actions and notifications which could be replaced by closures. We could deprecate or provide warnings when trying to use the Selector Apis in swift.
Others with more tend to be for canPerformSelector which is replaced by optionals.
The one edge case not handled is nsinvocation or performSelector, I would be interested why people use this use case and how we would replace it in swift (if at all).
2. How are we supposed to implement this? You need to somehow convert a closure (a pointer to a bunch of captured variables with a pointer to a function embedded inside it) into a selector (a pointer to a table of selectors inside the Objective-C runtime, which does not do any normal memory management); I just don't see how you make that work. Saying "let's do this thing" doesn't mean it's *possible* to do the thing.
I get that they are different but I had the idea that the compiler could generate a unique name for each closure which when referenced by a selector it would invoke.
But this would be irrelevant if we moved towards closure Apis.
3. What about other uses for selectors? addAction() is all well and good, but you also need removeAction(), and Swift closures don't have stable identities to test with.
I question when we use things such as removeAction? I've only used addAction. But I guess again if we moved to closure Apis this point would be moot.
To me the only case that needs selectors is performSelector or Nsinvocation. The others can be replaced by closures and the selector api to be deprecated or to show a warning in swift :) (Xcode could even help migrate by moving it to a closure that calls the function the selector was pointing to)
I'm not a compiler expert so I rely on the swift team to tell me what's possible (although at this early stage I think it's more important to figure out what we want and not be bound by what's possible right now)
How would the closure based API work with Interface Builder ?
NSControl and subclasses have an action property and a target property but no method to set both at once (in opposition to, say, NSTimer, which has methods that accept a target and a selector at the same time).
Félix
···
Le 30 déc. 2015 à 11:52:41, James Campbell <james@supmenow.com> a écrit :
Do you have an example of use ?
Sent from my iPhone
On 30 Dec 2015, at 15:48, Félix Cloutier <felixcca@yahoo.ca> wrote:
How do you import the API to Swift when the target and action properties are separate?
Félix
Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so :
addAction(myClass.actionFunction)
Instead of what it does now:
addAction(myClass, action:"actionFunction:")
Sent from my iPhone
On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mailing@xenonium.com> wrote:
Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution <swift-evolution@swift.org> a écrit :
These are very good points.
Actually, it comes in as addAction(action: Selector), not String. You can initialize a Selector from a string literal.
Yes :) should have looked it up before I tried to remember it off the top of my head.
Three questions about your proposal:
1. Where does "AnyObject -> Void" come from? The only signature information in a selector is the (minimum) number of arguments. Those arguments can be of any type, and
Well I would want to know what selectors people would us:
One with one argument tend to be for events like button actions and notifications which could be replaced by closures. We could deprecate or provide warnings when trying to use the Selector Apis in swift.
Others with more tend to be for canPerformSelector which is replaced by optionals.
The one edge case not handled is nsinvocation or performSelector, I would be interested why people use this use case and how we would replace it in swift (if at all).
2. How are we supposed to implement this? You need to somehow convert a closure (a pointer to a bunch of captured variables with a pointer to a function embedded inside it) into a selector (a pointer to a table of selectors inside the Objective-C runtime, which does not do any normal memory management); I just don't see how you make that work. Saying "let's do this thing" doesn't mean it's *possible* to do the thing.
I get that they are different but I had the idea that the compiler could generate a unique name for each closure which when referenced by a selector it would invoke.
But this would be irrelevant if we moved towards closure Apis.
3. What about other uses for selectors? addAction() is all well and good, but you also need removeAction(), and Swift closures don't have stable identities to test with.
I question when we use things such as removeAction? I've only used addAction. But I guess again if we moved to closure Apis this point would be moot.
To me the only case that needs selectors is performSelector or Nsinvocation. The others can be replaced by closures and the selector api to be deprecated or to show a warning in swift :) (Xcode could even help migrate by moving it to a closure that calls the function the selector was pointing to)
I'm not a compiler expert so I rely on the swift team to tell me what's possible (although at this early stage I think it's more important to figure out what we want and not be bound by what's possible right now)
How would the closure based API work with Interface Builder ?
I'm not as familiar with OS X but why is it vital there ?
Do you have an example of use ?
If those questions are for me ;-):
Afair (have to do iOS most of the time now), "Undo" is the most prominent example. You don't link those menu entries to a concrete object, but rather say "bind this to a selector whose name is…", and then the system can determine the actual target (there may be many controls which support undo).
Additionally, before this can happen, the system has to determine wether an entry is enabled at all — you can't do this when you have only a simple closure.
Good point. Not sure if that's replaceable via a protocol or if that Api is just not suited for swift.
There is a proposal somewhere to be able to reference swift methods via back ticks a sort of selector for swift so maybe in this case we would use that.
···
Sent from my iPhone
On 30 Dec 2015, at 20:27, Tino Heth <2th@gmx.de> wrote:
I'm not as familiar with OS X but why is it vital there ?
Do you have an example of use ?
If those questions are for me ;-):
Afair (have to do iOS most of the time now), "Undo" is the most prominent example. You don't link those menu entries to a concrete object, but rather say "bind this to a selector whose name is…", and then the system can determine the actual target (there may be many controls which support undo).
Additionally, before this can happen, the system has to determine wether an entry is enabled at all — you can't do this when you have only a simple closure.
On 31 Dec 2015, at 01:33, James Campbell <james@supmenow.com> wrote:
Good point. Not sure if that's replaceable via a protocol or if that Api is just not suited for swift.
There is a proposal somewhere to be able to reference swift methods via back ticks a sort of selector for swift so maybe in this case we would use that.
Sent from my iPhone
On 30 Dec 2015, at 20:27, Tino Heth <2th@gmx.de> wrote:
I'm not as familiar with OS X but why is it vital there ?
Do you have an example of use ?
If those questions are for me ;-):
Afair (have to do iOS most of the time now), "Undo" is the most prominent example. You don't link those menu entries to a concrete object, but rather say "bind this to a selector whose name is…", and then the system can determine the actual target (there may be many controls which support undo).
Additionally, before this can happen, the system has to determine wether an entry is enabled at all — you can't do this when you have only a simple closure.