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
