Okay - Xcode just finished installing and I got to see my code in situ with
fixable warnings.
myButton.addTarget(self, action: "selected:", forControlEvents: .TouchUpInside)
//above shows fixable warning. Changes to this:
myButton.addTarget(self, action: #selector(AudioElement.selected(_:)),
forControlEvents: .TouchUpInside)
I get it now that I can see what's going on with better context. I can also
just replace AudioElement with self.
On Tue, Mar 22, 2016 at 9:30 AM Eric E. Dolecki <edole...@gmail.com> wrote:
> Thanks for the answer. I am going to read it a few times.
>
> Back to the original question - if an object has an addTarget, will
> calling the non-string method name supply the object itself to the method?
>
> On Tue, Mar 22, 2016 at 9:28 AM Luther Baker <lutherba...@gmail.com>
> wrote:
>
>> Thanks for posting this extended answer!
>> On Mon, Mar 21, 2016 at 11:34 PM Quincey Morris <
>> quinceymor...@rivergatesoftware.com> wrote:
>>
>>> On Mar 21, 2016, at 20:27 , Eric E. Dolecki <edole...@gmail.com> wrote:
>>> >
>>> > Quick question. If I use #selector(funcName) - does it always send an
>>> > argument of the obj if the func requests it or not?
>>> >
>>> > If the function being called has a typed argument of something like
>>> > sender:UIButton, I can reference the sender in the func. Before with a
>>> > string we could add the ":" to inform that it would be supplied. Now
>>> is it
>>> > implied that it will be supplied?
>>>
>>> 1. The “:” was never optional, in the sense that you could choose
>>> whether or not to “add” it. Obj-C @selector(funcName) and
>>> @selector(funcName:) — “funcName” and “funcName:” in the previous Swift —
>>> are completely unrelated selectors. When performing the first of these
>>> selectors, there was never a parameter, and when performing the second
>>> there was always a parameter.
>>>
>>> 2. Selectors don’t send messages, selectors *are* messages. They are,
>>> approximately, polymorphic (class-independent) method names known to the
>>> runtime.
>>>
>>> When performing a selector, it has always been necessary to supply the
>>> correct number of arguments. It was an implementation detail of the Obj-C
>>> runtime that omitting or oversupplying parameters would not necessarily
>>> crash, and this fact could be exploited sometimes.
>>>
>>> 3. The new #selector syntax specifies the method by qualified name (via
>>> an expression that isn’t evaluated). For example:
>>>
>>> > import Cocoa
>>> >
>>> > let x1 = #selector (NSView.addSubview(_:))
>>> >
>>> > let v: NSView
>>> > let x2 = #selector (v.addSubview(_:))
>>> >
>>> > class A: NSView
>>> > {
>>> > let x3 = #selector (addSubview(_:))
>>> > }
>>>
>>>
>>> These 3 declarations specify the single-parameter addSubview method
>>> explicitly, by specifying the parameter keyword (_). They differ in the way
>>> they tell the compiler which class to consult to determine whether/how
>>> ‘addSubview:’ is declared.
>>>
>>> But Swift has additional source code forms. If it’s unambiguous which
>>> method is meant, you can just use the method name without keywords:
>>>
>>> > class A: NSView
>>> > {
>>> > let x4 = #selector (isDescendantOf) // OK because there is only
>>> one matching method
>>> > let x5 = #selector (addSubview) // ambiguous
>>> > }
>>>
>>>
>>> and you can use ‘as’ to specify the type of function, to distinguish
>>> between overloaded functions that have the same name and parameter
>>> keywords, but different parameter or return types.
>>>
>>> Note that x4 corresponds to Obj-C @selector(isDescendantOf:), not
>>> @selector(isDescendantOf).
>>>
>>> 4. Swift selectors are still polymorphic, so they aren’t tied to a class
>>> at runtime. For example, x1 above doesn’t mean “the selector for
>>> ‘addSubview:’ in class NSView". It means “the selector for method
>>> addSubview:, using NSView’s addSubview: method as a pattern to resolve any
>>> ambiguities”. You can still perform such a selector on any class that has a
>>> matching method, just like in Obj-C.
>>>
>>> 5. The problem being solved here is that in Obj-C the compiler can’t
>>> check that a selector is valid. There are two parts to this:
>>>
>>> a. It can only check that a method exists for a selector if a header
>>> file declaring that method is #imported into the current compilation.
>>>
>>> b. It cannot check the return type safely under any circumstances,
>>> leading to crashes when methods exist with the same selector but different
>>> return types.
>>>
>>> Swift solves the problem by requiring you to be explicit about which
>>> function signature the selector represents.
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>>>
>>> This email sent to lutherba...@gmail.com
>>
>>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
