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 (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
