CoreBase toll-free bridging

[Luboš Doležel]

Hi,

I've started working on toll-free bridging support for gnustep-corebase. 
I'm pushing my work to github:

https://github.com/LubosD/gnustep-corebase

So far I have NSString/CFString and NSArray/CFArray somewhat working and 
I'm moving to other types.

The bridging is implemented via a helper category, so nothing in Base 
had to be touched for bridging to work in both directions. Given 
CoreBase's alpha state, it's the only feasible option anyway, I guess.

There is one thing I cannot easily fix, though. @"Strings". On OS X, 
@"string" is a direct equivalent of CFSTR("string"). In other words, a 
constant CFString instance is created in the resulting binary.

On Linux, though, we get this by default: 
http://gcc.gnu.org/onlinedocs/gcc/Constant-string-objects.html
I don't see any reasonable/maintainable way of making this struct 
working with CFString; I believe the best way forward is to adapt 
Apple's approach and generate __CFString structs for every @"aaa".

This is where ABI comes in, so David, what is your opinion? My suggestion:

1) Have clang generate __CFString's
2) Adapt NSConstantString to support this new struct layout
3) Make the CFTypeID of CFString constant forever (this is what they had 
to do in Apple CF/CFLite), as it will be part of the ABI

As an aside, it should be discussed whether CoreBase's __CFString should 
contain a "hashCode" field. The one from Apple does not. I would make it 
go away for two reasons:

1) It gives me a headache in Darling, because this extra field doesn't 
fit into the original struct when doing fixups :-)
2) It makes the hash computation part of the ABI

Bye,
--
Luboš Doležel