Re: [Pyobjc-dev] FourCharCodes vs. PyObjC

[Ronald O. <ous...@ci...>]

On 14 nov 2003, at 17:38, Bob Ippolito wrote:

> In Python, four char codes are strings of length four.  PyObjC sees 
> the signature of FourCharCode as an unsigned integer.  This is bad, 
> AFAIK there is no "signature character" that we can use to specify a 
> length of four.. so basically I have some 30 or so, maybe more, 
> mappings to write just to provide FourCharCode to string of length 
> four compatibility.
>

I was going to suggest to use NSFileTypeForHFSTypeCode to do the 
conversion, but then noticed that this already uses PyMac_...OSType and 
therefore won't accept integers.

How are you supposed to use 4 char codes in C? Given the way MacPython 
represents them I suppose you commonly represent them as "very wide 
characters" (e.g. 'flop'), instead as integers.

The introduction about HFSTypes in the Foundation reference talks about 
the attributes dictionary for files, such as with the 
changeFileAttributes:atPath: method. Those are even harder to handle 
than plain method arguments, for the latter we could devise some scheme 
to tell the bridge that some uint argument is a 4char code, doing this 
for random dictionaries is much harder.
>
> This is mostly a question for Ronald I guess, but how would this best 
> be done?  Basically what needs to be done is a lot of PyMac_GetOSType 
> and PyMac_BuildOSType all over the place.. or else people will have to 
> struct.unpack('L', fourCharCode)[0] everywhere, which is not fun.  A 
> potential solution to this would be to add a signature character, or 
> to allow length of 4 strings for any uint32.. but I'd also like to see 
> things come out of PyObjC as length of four character strings.

Allowing 4-character strings for unsigned int values is out, there's 
much more unsigned ints than just the 4-character codes.

It is impossible to add new signature characters, the signature strings 
correspond directly with the signature strings that are used by the 
ObjC runtime. We override the signatures for some methods, but that's 
just to add additional information that could have been added by the 
compiler if the header files contained enough information (e.g. 
input/output argument information).

One option would be to add an optional array of argument convertors to 
selector objects that would be used instead of the default convertor. 
I'm not sure if this would buy us much (e.g. if it is only usefull for 
the 30-something methods that use fourcharactercodes it is probably not 
worth the effort to implement such a scheme)

>
> Also, how can I transparently bridge AEDesc with 
> NSAppleEventDescriptor?  They're basically the same thing.

Basically the same or exactly the same? Is an AEDesc transparently 
bridged to NSAppleEventDescriptor in Objective-C? If it is, we can add 
a test to toll-free-bridging.m.

Ronald