Re: why does this method return an id?
Re: why does this method return an id?
- Subject: Re: why does this method return an id?
- From: Charles Srstka <email@hidden>
- Date: Tue, 13 Dec 2011 04:14:42 -0600
On Dec 13, 2011, at 12:39 AM, Matt Neuburg wrote:
> On Sun, 11 Dec 2011 12:34:57 -0600, Charles Srstka <email@hidden> 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?
Right, but if you *did* override sortDescriptorWithKey:ascending:, then you certainly *wouldn’t* deserve the warning. Kind of like the subclass convenience constructors work with many of the existing Cocoa classes:
- [NSString string]
- [NSMutableString string]
- [NSIndexSet indexSet]
- [NSMutableIndexSet indexSet]
- [NSURLRequest requestWithURL:]
- [NSMutableURLRequest requestWithURL:]
Notice how of these examples, only NS(Mutable)?String is a class cluster. None of these convenience methods would work right for the mutable subclasses if they weren’t typed to id. If you got a warning every time you created a mutable instance of these classes, it would certainly not be *good*.
> 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?
I would presume so. However, in order to say for sure, I’d need to see some of the examples of convenience constructors that aren’t typed as id. I can’t think of any off the top of my head, although I’m sure there are probably some in there.
Charles_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden