Thanks for posting this extended answer! On Mon, Mar 21, 2016 at 11:34 PM Quincey Morris < [email protected]> wrote:
> On Mar 21, 2016, at 20:27 , Eric E. Dolecki <[email protected]> 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 ([email protected]) > > 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 [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
