views:

158

answers:

2

In Objective-C (at least, the Apple flavor of Obj-C), why is SEL not a class? Is it a matter of efficiency? Is it to prevent some sort of infinite recursion? Was there merely no incentive to make SEL a class? Speculation welcome, but please let me know if an answer is historical truth or speculation.

+5  A: 

It goes back to the earliest versions of Objective-C. If I could find my copy of the Objective-C book, I could give you a reference, but I think it just wasn't obvious what the benefit would be. The early versions of Objective-C were very minimal extensions of the C syntax.

In GCC, the SEL type was implemented as a const char *, pointing to a string representation of the selector's name. This implementation took advantage of constant string coalescing, which was already implemented in the compiler, to ensure uniqueness of selector values.


"The book" of course is referring to Object-Oriented Programming: An Evolutionary Approach. Thanks for jogging my memory Friedrich.

Mark Bessey
Which book are you referring to?
outis
I assume this is meant:http://www.amazon.com/exec/obidos/ISBN%3d0201548348/virtualschoolA/RegardsFriedrich
Friedrich
Yep, that's the one. Thanks for the link. I think it's still well worth reading.
Mark Bessey
A: 

Making it a class type adds little or no benefit. If it were an NSObject subclass it would be a tremendous amount of overhead for something that is effectively supposed to be a unique identifier. To dispatch an Objective-C call at that point would incur a penalty such a perfomance critical section of code can't afford to pay.

And yes, I'm speculating as to justifications why the type is what it is.

fbrereto
It certainly couldn't be an NSObject subclass since it NSObject is not part of the core Objective-C language.
Chuck
There would be no overhead related with making an SEL into a class, save for a little bit of memory.
bbum
What code section are you referring to? Most code wouldn't require dispatching messages to SELs and thus wouldn't incur any penalty. As for lack of benefits, that seems a hard statement to prove. Making data types orthogonal usually has some benefits, such as allowing all data to be stored in collections without resorting to wrapper types.
outis