On May 30, 2011, at 13:45, julius wrote:
> Hilarity and riot.
Glad to have been of service.
> Here is a nice instance that I think quite germane.
>
> The input parameter to NSArray's objectAtIndex: is an NSUInteger.
> Both these code snippets work perfectly (they retrieve element 3).
> zStr = [zAry objectAtIndex:3.1];
> and
> CGFloat zF1 = 3.2;
> zStr = [zAry objectAtIndex:zF1];
>
> I'm sure that by setting the right flags one could get warning messages to
> appear.
OK, but why are you picking on NSArray? Here's another method that exemplifies
exactly the same problem:
- (id) iMadeThisUp: (unsigned int) theNumberIFirstThoughtOf { ... }
It's a defect in ObjC that comes directly from a defect in C.
Now that we've reduced this to a C issue, let me try to provoke more hilarity
and riot by re-characterizing your objection:
-- You want integer calculations in C to be carried out in a unique abstract
numerical space.
By "unique", I mean that there aren't different rules depending on the types of
the integers involved. By "abstract" I mean that the numerical range is
conceptually infinite. The only constraint is that the result should be
representable in (?) the variable type of the destination variable, or
something like that.
This is a perfectly sensible idea. It is in fact a lot like how C works with
floating point -- intermediate calculations are performed in type 'double',
even if the values are type 'float'. In effect, C has no "arithmetic" type
'float', only a "storage" type 'float'. (Terminology applied loosely here.)
Unfortunately, somebody decided a long time ago, the same can't be done for
integers, because there's no infinite-range numerical space available to
machine computation (in any way that mainstream hardware supports directly),
and no single finite-range space that (as in the floating point case)
encompasses the others.
As a result, in C, the numerical space of the expression really does depend on
the types of the variables involved. The arithmetic operators, even + and -,
*mean* different things for signed and unsigned arithmetic. You should read
that last sentence twice, because it's the heart of the matter.
There is, additionally, a horrible mish-mash of conversion rules that mean that
much of the time you can ignore the difference when writing source code, but at
your peril.
You want different conversion rules? Fine. You want warning messages? Fine. You
want a unique abstract numerical space? Fine. You want type-independent
arithmetic operators? Fine. You want to get us a new language? Fine. But you
can't insist of writing code for a
language-roughly-similar-to-C-but-not-quite-the-same-thing and then complain
because it isn't C. *There's* the riot and hilarity. ;)
_______________________________________________
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
