Re: [Pyobjc-dev] FourCharCodes vs. PyObjC

[Bob I. <bo...@re...>]

On Nov 14, 2003, at 4:06 PM, Ronald Oussoren wrote:

> 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.

C is VERY weakly typed, 'asdf' is a perfectly good unsigned int.

> 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.

Yeah, but what's the worst that could happen if we accepted a 4 
character string as a valid input for an unsigned int out of context?

> 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).

The in/out/in-out specifiers are part of the ObjC runtime?

> 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)

Typing out wrappings for 30-something methods will make my hands tired 
:)

>> 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.

No, it's not a transparent bridge.  A NSAppleEventDescriptor 
encapsulates an AEDesc.  What I was asking really, is how can I pass a 
Carbon.AE.AEDesc to an ObjC method that expects an 
NSAppleEventDescriptor without doing 
NSAppleEventDescriptor.alloc().initWithAEDescNoCopy_(somePythonAEDesc) 
every time.  I was referring to the mechanism that makes NSString and 
Python unicode interchangable, not CoreFoundation<->Foundation toll 
free bridging.

-bob