On Dec 13, 2011, at 12:39 AM, Matt Neuburg wrote: > 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?
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 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]
