Re: [Pyobjc-dev] FourCharCodes vs. PyObjC

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

On 14 nov 2003, at 22:24, Bob Ippolito wrote:

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

Is it? GCC on my linux box warns about 'asdf':
t.c:5:17: warning: multi-character character constant

On the other hand, the C9X draft says that 'abcd' is indeed syntacticly 
correct, and mapped in some implmentation defined onto a multi-byte 
character (look for character-constant in 
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm). I haven't 
checked if the document says anything about the range of values for 
character contants (specificaly if that range must be the same as the 
range of values for char).

But, this is all pretty theoretical and not relevant to the discussion 
:-)

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

With the additional support problems that that will give. Those 
problems will not come up very often, which means we'll have to think 
very hard when someone asks why his code fails for some values and not 
for others.

>
>> 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?
Yes, it's part of the Distributed Objects stuff. If you define formal 
protocols in ObjC you can specify in/out/inout arguments to make sure 
that DO can correctly marshall the arguments.

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

Another possible hack: In the PPC ABI types 'struct foo { long x }' and 
'long' are equivalent. We could exploit this by recognizing the 
signature string '{_PyObjC_FourCharacterCode=I}' as a four character 
code and doing something special for that.

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

NSString and Python unicode/str are explicitly bridged in 
objc_support.m. Automatic conversion between AEDesc and 
NSAppleEventDescriptor might be very convenient, but is it a good idea?
Ronald