[Top][All Lists]

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

Re: Discovery from class-dumping Yosemite system libraries.

From: 陈北宗
Subject: Re: Discovery from class-dumping Yosemite system libraries.
Date: Thu, 9 Apr 2015 03:48:28 +0800

I am thinking about a new TFB semantics actually. (not compatible with ARC, but 
not really an issue as CF is not ARC anyway)

Because of this, leveraging Objective-C’s @defs():

@interface NSPlayground : NSObject
  id object;
  // …


typedef struct CFPlayground
} *CFPlaygroundRef;

This will guarantee NSPlayground and CFPlayground have exactly the same layout.

This is an obscure feature of Objective-C, and it is probably only useful to 
make TFB happen.

This does have limitations as it would be better for us to put TFB-able classes 
in CF (despite keeping it headers in Foundation.)

Then about the methods, I would suggest minimal bridging TFB for some classes, 
and CF-only for some other. Minimal bridging works like this: both CF and 
Foundation define a common set of methods as minimal implementation 
requirements. Those methods check if an CF or Foundation object is called using 
the “wrong” interface, and bridge to the counterpart if so. CF-only works in 
the sense that all Foundation calls bridges to CF by default, on top of the 
minimal bridging. NSArray, NSDictionary and the like are designed using minimal 
bridging (as we have distinct _NSArrayI and _NSCFArray concrete classes), while 
NSString is CF-only (as other than NSConstantString we have only _NSCFString)

> On Apr 8, 2015, at 18:21, Luboš Doležel <address@hidden> wrote:
> On 04/08/2015 12:11 PM, ChanMaxthon wrote:
>> Apple did not make NSSet/CFBag and NS/CFRunLoop TFB but we can make that 
>> happen without breaking Apple's interface contracts.
> Based on the design, NSRunLoop is an upper level wrapper of CFRunLoop
> adding extra operations. I wouldn't find adding TFB very useful in this
> case, I'd much rather focus on finishing the implementation of other
> TFB'd classes.
> This is what I'd personally like to do in near future, but I'm currently
> busy with porting original Apple's libSystem sources to Linux/Darling.
> -- 
> Luboš Doležel
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

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