Re: Size of -[NSEvent type]

FROM : Ali Ozer
DATE : Fri Nov 30 19:28:41 2007

> The transition documentation suggested to me that the decision 
> whether to
> convert to NSInteger and NSUInteger was somewhat more 
> discriminating, and
> that some ints and unsigned ints weren't changed


No, the change was pretty global. The only types that did not move 
were those where the underlying C type or the size are significant in 
the API or functionality; for instance, initWithInt: vs 
initWithInteger: in NSNumber, or intValue vs integerValue in NSCell. 
Similarly, with floats, all graphical floats moved to CGFloat, and the 
only remaining occurrences of float are those where the underlying C 
type is important, or the value is not graphical (such as volume 
method in NSSound).

In general, moving forward, all Cocoa apps should just use NSInteger 
or NSUInteger for their integral types, and APIs. One scenario where 
it's interesting to consider a smaller type is in fields of widely 
allocated objects, as a way to save on storage. However the accessors 
for those properties would still likely be in terms of NSInteger or 
NSUInteger.

> I asked because I'm writing an Objective-C wrapper framework for 
> Quartz
> event taps. I'm struggling to decide what conventions I should 
> follow with
> regard to typing the values I'm wrapping, such as CGEventType.


In this one case using uint64 might be reasonable, and would 
accommodate some possible future scenarios.  Say we added more event 
types that we had to support under 32-bit, requiring us to perhaps add 
some new APIs representing event masks as 64-bit quantities. On the 
other hand we don't have any case of this in Leopard, so I think 
NSUInteger is just fine, and might be preferable if you wish the keep 
the API a little more consistent.

Ali





On Nov 30, 2007, at 09:36 , Bill Cheeseman wrote:

> on 2007-11-30 11:11 AM, Ali Ozer at <email_removed> wrote:
>

>> All int-sized types in Cocoa moved to NSInteger or NSUInteger under 
>> 64-
>> bit, so what happened to NSEventType is consistent with everything
>> else.  This is true even if the type in question isn't likely to hold
>> a value greater than 2 or 4 billion in the foreseeable future.
>>
>> As far as masks, the 32-bit mask has been getting close to full, so 
>> we
>> even considered moving to a 64-bit mask under 32-bit.  However, since
>> this would be a binary incompatible change for NSEvent and likely
>> require new APIs to do right, we instead allow for a 64-bit mask 
>> under
>> 64-bit only.  Clearly the top 32-bits can't be except in 64-bit
>> scenarios, and we're not making any use of it at this point.

>
> Thanks for the info.
>
> The transition documentation suggested to me that the decision 
> whether to
> convert to NSInteger and NSUInteger was somewhat more 
> discriminating, and
> that some ints and unsigned ints weren't changed. I wondered why 
> NSEventType
> wasn't one of those special cases, since it seems unlikely that 
> we'll see
> more than 2 billion different event types even in the unforeseeable 
> future.
>
> I asked because I'm writing an Objective-C wrapper framework for 
> Quartz
> event taps. I'm struggling to decide what conventions I should 
> follow with
> regard to typing the values I'm wrapping, such as CGEventType. Being 
> focused
> on Cocoa, I prefer to follow NSEvent's conventions as closely as 
> possible.
> But, to my surprise, there are some declarations in CGEvent.h (namely,
> CGEventFlags and CGEventMask) that are uint64_t and therefore yield 
> 64-bit
> variables whether you're running as 32-bit or 64-bit -- yet their 
> NSEvent
> counterparts (e.g., NSEventMask) can be 32-bit running as 32-bit.
>
> I guess you're telling me that the top 32-bits aren't likely to be 
> used in a
> 32-bit environment until NSEvent's equivalent is re-typed as 
> uint64_t or
> long long. So I'm safe for the time being using the NSEvent 
> conventions. (As
> long as I'm right in thinking that CGEvent and NSEvent are closely 
> linked. I
> assume they are, since they both seem to rely in one way or another on
> IOLLEvent.h in the IOKit framework.)
>
>
> --
>
> Bill Cheeseman - <email_removed>
> Quechee Software, Quechee, Vermont, USA
> www.quecheesoftware.com
>
> PreFab Software - www.prefabsoftware.com
>