Re: CoreBase toll-free bridging

[Luboš Doležel]

On Wed, 27 Mar 2013 08:57:33 +0800, Maxthon Chan wrote:
> However this is the Apple approach. Can we just think out of the box
> and maintain just API interoperability?

Honestly, the main reason I'm not so much in favor of this is it feels 
like a waste to throw away most of the code Stefan Bidi has written.
The biggest advantage of what you're proposing are maintainability 
(core reuse) and stability (Base is already in use). GNUstep probably 
doesn't have manpower to give CoreBase as much love as Base.

I guess all the differences between CF and F (such as the ability to 
have non-CF/NS types in CFArrays) can be worked around somehow, at least 
in case of types that are officially toll-free bridged.

> As I said, Apple used Core Foundation to serve both Cocoa and Carbon
> simultaneously, which is asking for a C API (Cocoa was in Objective-C
> and Carbon was C++, and there wasn't a good implementation of
> Objective-C++ then to allow implementing Carbon or Cocoa on top of
> each other, thus a C API is called for and Core Foundation is born.
> Before Cocoa, in NeXTSTEP ages, the NeXTSTEP libraries sits directly
> on libobjc and libc, just like current GNUstep.) So once again, it is
> okay for us to directly implement the entire CoreBase on top of Base?
> Not to say that this will make CoreBase code more portable as it no
> longer rely on the internal structure of the Objective-C runtime (To
> the extent that one can even port CoreBase back to OS X if any
> CoreBase extras is called for on an OS X app).

My work on toll-free bridging is nearing completion (but I haven't 
written tests to check if it's all working yet): 
http://darling.dolezel.info/en/Core_Foundation
After this is all done and I submit my work upstream, I'll create a 
separate branch to test this approach.

> And just another idea, given that clang is now powerful enough, it is
> actually possible for us to implement Carbon in Objective-C++ based
> directly on Foundation (or Base).

This would have been interesting a couple of years ago. But given 
Apple's current position on Carbon....

Right now, the best way forward in my opinion is:

- Have a central TODO list of missing NS classes and methods. I 
couldn't find any.
- Integrate gnustep-opal.
- Implement CoreAnimation.
- Implement AppleEvents + their NS wrapper classes.
- Maybe implement AudioToolbox, CoreAudio... 
(http://svn.gna.org/viewcvs/gnustep/libs/audiotoolbox/)

But that depends on what GNUstep's central goal is.

--
Luboš Doležel