Re: (RS)What's the type of a selector?[2]
Re: (RS)What's the type of a selector?[2]
- Subject: Re: (RS)What's the type of a selector?[2]
- From: Roland Silver <email@hidden>
- Date: Sat, 28 Oct 2006 00:53:11 -0600
Yes, thanks, Bill. I'm respectful of the idea that the type of
objc_selector -- hence of SEL* -- is hidden, and might change with
time. What I didn't know (but has been pointed out since) is the
existence of the NSStringFromSelector function, which is sufficient
to answer the other part of my question: how to print the selector.
--Roland Silver <email@hidden>
On Oct 28, 2006, at 12:26 AM, Bill Bumgarner wrote:
On Oct 27, 2006, at 7:24 PM, Roland Silver wrote:
John, the question remains, what do I put in for
%??
in
obj_selector bar = @selector(foo);
NSLog(@"%??", bar);
in other words, what's an obj_selector?
Aaron Hillegass gave me a straight answer to my original question:
-------------------------
It is actually a char *:
- (void)foo {
NSLog(@"%s", @selector(foo));
}
On Oct 27, 2006, at 6:52 PM, Roland Silver wrote:
What's the type of a selector? I gather it's a SEL -- but what's
a SEL, as far as trying to print one using NSLog is concerned?
-------------------------
So I gather that a SEL is merely a char*. Que no?
If you want to log a selector -- a SEL -- then use:
NSLog(@"The selector is: %@", NSStringFromSelector
(someRandomSelector));
Which can be useful in any random method's implementation in that
you can do this:
NSLog(@"The currently executing method is: %@",
NSStringFromSelector(_cmd));
The above is the "most correct", "least fragile", pattern for
logging the selector.
Now, SEL is defined as:
typedef struct objc_selector *SEL;
Which really doesn't help much unless you know the definition of an
objc_selector. Now, unfortunately, the above is anonymous or
forward structure declaration. It really only says that SEL is a
pointer to a structure whose content this particular header doesn't
think you need to know about. Fortunately, objc source is
available and you can download the source from the darwin
repository (http://www.opensource.apple.com/darwinsource/10.4.7.ppc/).
That objc treats SEL as (char *) internally is an implementation
detail. It may even be a relatively documented implementation
detail, but a detail it is and it is a detail that'll lead to less
efficient coding, if you aren't careful.
For example, Cocoa's standard menu validation mechanism enables/
disables menu items based on their action. An action is just an
SEL. Equating SEL to (char *) would indicate that one should use
strcmp() to determine if a particular action is equivalent to a
particular selector (i.e. if the menu item invokes the -copy:
action and you want to disable the item if a particular object is
selected), but Cocoa is documented as requiring the following
validation pattern:
- (BOOL)validateMenuItem:(NSMenuItem *)item {
if ([item action] == @selector(copy:))
return NO;
return YES;
}
So, YES, an SEL is a (char*). But, NO, that doesn't mean that SEL
doesn't come with additional rules, requirements, and opportunities.
You certainly could do...
NSLog(@"The currently executing method is: %s", (char *)@selector
(copy:));
.... but that isn't as clean as using the API. The typecast
assumes knowledge of the API that is not reflected in the header
file. It effectively prevents the compiler from doing its
validation job. Furthermore, sticking with the non-cast-required
higher level APIs guarantees that your code won't break even if the
typedef of SEL were to change -- unlikely, but it could happen if
Apple were to decide that there was a huge benefit to changing the
ObjC ABI.
b.bum
--Roland Silver <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden