Re: Why does NSArray count return NSUInteger?
Re: Why does NSArray count return NSUInteger?
- Subject: Re: Why does NSArray count return NSUInteger?
- From: Quincey Morris <email@hidden>
- Date: Mon, 30 May 2011 10:41:40 -0700
On May 30, 2011, at 08:27, julius wrote:
> All I had hoped was that someone on this list might illuminate the issue more than has happened so far.
The problem isn't really lack of illumination, but that you're not prepared to accept the consequences of the explanation.
Here's my version of the illumination:
The designers of the Cocoa APIs -- in common with designers a lot of other APIs -- have followed a general design principle, which is to use the parameter/return type that most accurately describes the data being passed. The purposes of this, presumably, include:
-- It's self documenting to a degree.
-- It at least theoretically provides opportunities for compile-type (== better) error messages if you accidentally pass a value of the wrong type.
-- It at least theoretically eliminates the need to code some range validation checks.
along with other reasons I can't think of right now.
None of those reasons is perfect. That's in part because the C language isn't strict enough for the purpose (e.g. it's very lax in distinguishing between enum and int values), and in part because Cocoa APIs have come to make some compromises (e.g. for 32/64 transition reasons, Cocoa mostly doesn't use enums any more), or have set in stone some inconsistencies (row indexes in NSTableView being NSInteger, with -1 meaning an invalid index vs. element indexes in NSArray being NSUInteger, with NSNotFound meaning an invalid index).
That, or something like it, *is* the reason. But you won't accept it, because that isn't really the issue that's put a bee in your bonnet.
What you've *really* been arguing is nothing to do with Cocoa at all. You've been arguing that in C (and C-based languages like Objective-C), it's unconscionable to make routine use of unsigned variable types, because it imposes a burden on the programmer to code -- specifically to write arithmetic expressions and comparisons -- in different styles depending on the types of the variables involved.
Yes, it's a burden, in the sense that you do need to know the type of the variables involved, and you do need to write code with that knowledge in mind:
if (signedVariable - 10 > 3) ...
if (unsignedVariable > 10 + 3) ...
The only solution to that would be to remove unsigned types from the language***. Perhaps you could even make a compelling argument for doing that. (After all, countless hours *have* been lost debugging problems arising from mixing signed and unsigned variables in source code.) By all means go out on the C streets and fight that battle, but blaming Cocoa for this seems like a waste of everyone's time.
***Well, what you've actually being arguing is that we should all agree to pretend that they're not in the language._______________________________________________
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