This is a relevant article
https://www.mikeash.com/pyblog/friday-qa-2015-12-25-swifty-targetaction.html?utm_campaign=iOS%2BDev%2BWeekly_medium=email_source=iOS_Dev_Weekly_Issue_231
For this topic
Sent from my iPhone
> On 31 Dec 2015, at 01:33, James Campbell wrote:
>
>
> Ah good point, in swift you can return a function as a closure (see that
> link) so interface builder could bind an action.
afaics this cannot work when myClass is nil:
The transponder chain might be invisible on iOS, but for OS X, it is vital.
Tino
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 a écrit :
>
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
+1 for that. Closures are much more swift-y than selectors (and honestly,
even in Objective-C, selectors are a pain to use). This would definitely be
nice, although I'm not quite sure if it's possible with reasonable effort.
Selectors are very, very different beasts.
On Wed, Dec 30, 2015 at 10:56
What if selectors arguments could be imported into swift to take a closure
instead ?
This would fit into the proposal to rewrite the imported objective c Apis
So
- addAction:(Selector)action
Becomes
addAction(action:(AnyObject)->Void)
Instead of
addAction(action:String)
Like it does
> What if selectors arguments could be imported into swift to take a closure
> instead ?
>
> This would fit into the proposal to rewrite the imported objective c Apis
>
> So
>
> - addAction:(Selector)action
>
> Becomes
>
> addAction(action:(AnyObject)->Void)
>
> Instead of
>
>
For reference, I'll just point out that there was an interesting discussion
about this topic at the beginning of December.
https://lists.swift.org/pipermail/swift-evolution/2015-December/000233.html
--
Michel Fortin
https://michelf.ca
___
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,
Sent from my iPhone
> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch wrote:
>
> This is a neat idea. Here are some of my thoughts after initial readthrough:
>
> - For symmetry with Obj-C code, how about using "@selector", such as
>
Would it be possible to add properties to closures/method objects?
Right now, it's possible to write:
> @objc
> class Foo : NSObject {
> func doSomething(value: Int) -> Int {
> return value + 1
> }
> }
>
> let method = Foo.doSomething
Maybe we could have
> On Dec 28, 2015, at 10:46 AM, Félix Cloutier wrote:
>
> Would it be possible to add properties to closures/method objects?
>
> Right now, it's possible to write:
>
>> @objc
>> class Foo : NSObject {
>> func doSomething(value: Int) -> Int {
>> return
I really only was talking about the case where the compiler knows that it's an
@objc method (with the understanding that the information is lost as soon as
you make an unattributed T -> U closure out of it).
Either syntax would make me happy.
Félix
> Le 28 déc. 2015 à 13:49:22, Joe Groff
This is a neat idea. Here are some of my thoughts after initial readthrough:
- For symmetry with Obj-C code, how about using "@selector", such as
@selector(UIView.`insertSubview(_:at:)`) ?
- Or, why bother with a new expression? Could the compiler just do this
automatically when it encounters an
I would add to what Joe mentioned above the fact that the concept of
"selector" may not mean a whole lot to developers who are first introduced
to Swift without any prior Obj-C or Cocoa experience. Thinking of them as
functions I believe avoids introducing complexity in the form of additional
Great idea, but why make it a free function instead of a Selector
initializer?
let sel1 = Selector(UIView.`insertSubview(_:at:)`)
let sel2 = Selector(UIView.`frame.get`)
Of course if there were such a thing as
GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion
to
16 matches
Mail list logo