.. going back on list ..
On 30-May-2011, at 9:18 PM, julius wrote:
>
> On 30 May 2011, at 12:28, Roland King wrote:
>
>>
>>
>>> In what contexts is that output going to be used?
>>> I think that like me people will tend to use it in contexts to do with
>>> accessing array elements
>>> e.g. x = [ary objectAtIndex:[ary count]-2];
>>
>> well if you haven't already confirmed that [ary count ] can never be less
>> than 2, or checked that [ ary count ] is larger than or equal to 2, or then
>> you shouldn't be trying to get the element at ( [ ary count ] - 2 ), you're
>> going to fail whatever the data type is, that's a logic error.
> The intention of the example was to show a context.
> Of course it would be an error if I did not check blah.
If you check then there is no issue with that statement and it works perfectly
well.
>
>>
>>> or modifying behaviour according to array size
>>> e.g. if(k1 < ([ary count] - k2)) {…
>>
>> again - if you don't already know that [ ary count ] >= k2, you should't
>> subtract k2 from it. if you don't know and want to do that statement with
>> one check use
> ditto.
ditto
>>
>> If( ( k1 + k2 ) < [ ary count ] ) ..
> please do not rewrite my examples
> I said
> if(k1 < ([ary count] - k2)) {
> This is not about optimisation
> but the reason why the designers chose to have NSArray count return an
> NSUInteger.
Neither was my 'rewrite' about optimization. Again if you know that [ ary count
] >= k2 then your if() statement will work as-written.
>
>>
>>> If we know that a variable is never going to return a negative value and
>>> that it is predominantly going to be used in an arithmetic context why
>>> force the programmer to think about coercing the type on each occasion of
>>> its use when failure to do so risks malfunction?
>>
>> You don't need to coerce it.
> well in the piece of code which gave rise to all this I do, unless I rewrite
> using umpteen more lines of code.
No you don't. If you use NSUIntegers everywhere and check your bounds as you
say you do, you don't need to coerce anything to anything.
>
>> NSUInteger works perfectly well in an arithmetic context. The programmer
>> needs to ensure that they treat the data type within its limits. You can't
>> add 20,000,000 to an unsigned char and expect it to work, similarly here you
>> have to be aware of the kind of variable you have and treat it
>> appropriately. That If( ( k1 + k2 ) < [ ary count ] ) is a good example of
>> that.
> Precisely the point of my question.
> Why create a linguistic construct that has the potential to create problems
> if it skips one's mind that NSArray count returns NSUInteger as opposed to
> NSInteger which would not.
They didn't create a linguistic construct to do anything. They used a variable
correct for the type of the data they are representing. As a programmer you
need to think every time you subscript an array "am I going outside the bounds
of the array doing this", similarly when doing mathematical operations on
things which represent 'sizes of things which cannot be smaller than empty'.
>>
>>>
>>> So was it really just because the number of array elements is never -3 that
>>> the Cocoa developers decided to make NSArray count return type NSUInteger?
>>
>> Yes. Because NSArrays cannot have less than 0 elements, so there is no point
>> at all having the size of an array have a potential negative domain. It's
>> meaningless. They didn't use a double or a float for size either, because
>> you can't have 2.5 things in an array or look up the point at Array[ 23.4 ],
>> well not with this kind of array.
> Ok. This mixes two types of usage.
> In the case of if(k1 < ([ary count] - k2)) we are speaking about a return
> value which is used in a variety of contexts.
>
> In the case of ary[x] we are speaking about how we identify a particular
> array element and in C having a restriction on the type is used to enforce a
> useful rigour. Other languages might not do this because they have different
> objectives.
>
> In the if(k1 < ([ary count] - k2)) case I am asking why impose an NSUInteger
> complication when to do so has the potential to create problems precisely
> because in other contexts ([ary count] - k2) delivers the more intuitive
> result.
Again, as long as you have checked that [ ary count ] >= k2 before you do that
if(), you're fine. Or you rewrite it with +, as I did, it avoids the issue
because it recognizes that sizes can be added, but cannot be subtracted without
checking first, because there is no such thing as a negative size. size minus
bigger size is not a defined concept.
>
>> They used the datatype which maps onto the thing they are describing, array
>> elements are non-negative integers, so they used NSUInteger.
> So are you saying that the designers made this decision solely because of a
> particular interpretation of dogma?
No. I am saying that semantically the 'size' of an array is a non-negative
integer and thus the correct way to represent it is with a data type which
represents non-negative integers.
> Julius
>
> http://juliuspaintings.co.uk
>
>
>
_______________________________________________
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
