On Sun, 11 Dec 2011 12:34:57 -0600, Charles Srstka <[email protected]> 
said:
>On Dec 11, 2011, at 10:58 AM, Matt Neuburg wrote:
>
>> There seems to be a small hole in my understanding of Objective-C. I sort of 
>> understand why alloc-init returns an id, but why do so many class method 
>> convenience instantiators also return an id? For example:
>> 
>> [NSSortDescriptor sortDescriptorWithKey:@"indexOrig" ascending:YES]
>> 
>> That method is declared as returning an id, which means you can use it 
>> accidentally anywhere, assign the result to the wrong thing, and get a 
>> mysterious crash. (Guess how I know that?) Now, I think I know why [NSString 
>> string] is declared as returning an id - it's because it's a class cluster, 
>> right? But NSSortDescriptor isn't a class cluster; the result really is an 
>> NSSortDescriptor. So why isn't it *declared* as an NSSortDescriptor? Thx - m.
>
>Most likely it’s to accommodate subclasses. If it weren’t declared to return 
>an id, then doing something like this:
>
>MyFancySortDescriptorSubclass *sortDescriptor = [MyFancySortDescriptorSubclass 
>sortDescriptorWithKey:@“Foo” ascending:YES];
>
>would cause a compiler warning.

But if you subclassed NSSortDescriptor and didn't override 
sortDescriptorWithKey:ascending: and expected [MyFancyEtc. sortDescriptorEtc.] 
to magically produce a MyFancyEtc. instead of an NSSortDescriptor, you'd 
*deserve* that warning. In fact, having that warning would be *good*. Why are 
we turning type checking *off* at a crucial moment like this?

Also, if that's the right answer (i.e. if it's all about subclassing), then I 
don't get why *every* convenience constructor isn't typed as an id. Are the 
counterexamples all things that one is expected never to subclass?

m.

--
matt neuburg, phd = [email protected], <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook_______________________________________________

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to