[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: __NSCF** classes and libobjc2 dependency on C++ runtime

From: Luboš Doležel
Subject: Re: __NSCF** classes and libobjc2 dependency on C++ runtime
Date: Tue, 04 Jun 2013 22:40:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 06/04/2013 08:19 PM, Maxthon Chan wrote:
I never intend to do what Apple did in their exact way. That is illegal
even in PRC. My intention is to a) write test cases around documented
API that both GNUstep and Apple have and capture what Apple emit from
them and b) replicate this result in a reasonable way using GNUstep, not
caring if the implementation detail is the same. If I ended up doing it
the exact way, well lucky me… I have no idea how Apple did that unless
it is something open-sourced (and I guess I can link LGPL code against
APSL code, right?) and I have no intention to clone it in a full blown
way, just the surface behavior.

So before I say anything more, just giving an example, in my
implementation of toll-free bridging the "type ID" is useless, as
CoreFoundation objects are identified by their companion classes. Here
is a sneak peek of what my propose is.


no offense! But, we already know how TFB works and the *infrastructure* for TFB is already in place in CoreBase.

I'd say it would be better to improve what GNUstep already has.

With that being said, what are the conditions for getting commit access to GNUstep's repo? I'd like to push my work on TFB into upstream, so that no work would go to waste.

Given the current state of TFB in CoreBase, I suppose I certainly wouldn't break anything ;-)

Luboš Doležel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]