Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
- Subject: Toll Free Bridging, wrapping the SearchKit, and One-Way Bridging
- From: Stuart Halloway <email@hidden>
- Date: Wed, 3 Dec 2003 16:21:42 -0500
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?
-Stu
_______________________________________________
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.