Re: Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
Re: Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
- Subject: Re: Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
- From: Scott Anguish <email@hidden>
- Date: Thu, 4 Dec 2003 01:16:43 -0500
On Dec 3, 2003, at 4:21 PM, Stuart Halloway wrote:
Hi all,
I've been looking into wrapping the SearchKit in a more usable,
Cocoa-style API. A couple of questions:
1. Are others feeling the same need? I'd be more than happy not to
reinvent this wheel.
2. Wouldn't it be cool if SearchKit had wrapper classes that were
toll-free bridged, like NSString/CFString etc.? I have looked into
this and here are my results so far:
A. It is feasible to one-way bridge from a wrapper class back to a
SearchKit type. Simply have the wrapper instantiate the SearchKit
type, and swap in a different isa pointer, and replace self.
B. It is more difficult to bridge the other way. Since I don't control
the instantiation of SearchKit types, how can I change their isa
pointers? I can see two approaches, both fragile: I could use
class_addMethods, but the underlying type (NSCFType) is undocumented
and used in multiple places. Or I could link to a different library
that replaces the SearchKit's entry points.
The low-level hackery required to make this work leads me to believe I
should either wrap SearchKit w/o trying for toll-free bridging, or
hope the next big cat brings something better. Thoughts?
I think trying to toll-free bridge this isn't really a great solution.
First, you can't change the OO-API at all doing that.
Second, there isn't a gain. When Apple toll-free bridges something in
CF, there is a gain because Apple doesn't need to write and test a
second set of APIs, we don't need to doc them, and it's more
straightforward. You're writing the second set of APIs yourself, so
you gain nothing.
A SearchKit API in Obj-C would rock.. but I don't think attempting to
implement tollfree bridging is the best way for you to accomplish it.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.