Re: Toll-free bridge type at runtime
Re: Toll-free bridge type at runtime
- Subject: Re: Toll-free bridge type at runtime
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 03 Apr 2009 09:33:34 -0700
On Apr 3, 2009, at 12:22 AM, Ryan Joseph wrote:
The Pascal compiler I'm using would need some extra runtime support
(like telling me if a pointer is an object) to accomplish what you
are talking about, but yes that is the way it should work. I think
the Ruby and Python bridges made changes to the actual compiler also
that I'm not able to do so I need to look into other more creative
solutions.
Ruby/Python did not change the language compilers; they both work
entirely via the public APIs of both the interpreted language's
runtime and the Objective-C runtime's API.
Hence the motivation for my question; it is possible to do, but it
sounds like there may be a limitation in the Pascal compiler you are
using.
Thanks for your ideas.
Sure -- it is an interesting idea and I'm all for more languages being
bridged to Objective-C as long as the bridge authors promise to file
bugs along the way. ;)
RubyCocoa, PyObjC, and a number of other bridges are all proofs
that -- for said languages -- having indirect proxies in the
targeted language is not necessary. For PyObjC and RubyCocoa (now
MacRuby), the array classes are rendered in a compatible fashion
between the languages.
I bet those languages do something similar to what I am, that is
make a native Ruby class and within one of it's instance variables
store the Objective-C object, which is dereferences when passing the
Ruby object to Cocoa methods. The difference is I'm sure they added
runtime support to know if a generic pointer is a Ruby class or
otherwise so they can make safe choices at runtime.
They do that for the various classes that are, more or less, primitive
types within the runtime environment. Specifically, NSString,
NSArray, NSDictionary and NSSet (amongst others) are subclasses with
Ruby/Python native versions that can, because of class cluster
behavior, transparently pass across the bridge in either direction.
In this case, it very much is proxying. However, there is no notion
of needing to grab the handle to the foreign instance when passing the
object back across the bridge.
Instead, the bridge itself takes care of grabbing the native type out
of the object.
A similar mechanism is used for subclassing. However, the subclasses
truly are subclasses from their Objective-C parent classes and, thus,
the subclasses are perfectly viable on the Objective-C side of the
bridge, too.
That is, if via PyObjC, you pass a Python array to an Objective-C
method as a parameter, it is received as a subclass of NSArray that
"just works". Similarly, any random NSArray instance passed from
Objective-C into Python shows up as a python array object.
Now, maybe there is some particular design point of the Pascal
variant that you are targeting that prevents this.
Simply, if I attempt to dereference a pointer that is in fact a
CoreFoundation type it will crash. I need to know if it's a CFType,
and if not dereferencing is safe. Knowing if it was a Pascal object
would be just as good, but I don't have that option.
Alternatively, can you simply pass the Pascal object into whatever
mechanism takes care of the dispatch between Pascal and Objective-C,
have that mechanism detect that it received a Pascal object, and
dereference before passing along? This is, more or less, what the
Python/Ruby bridges do, with an additional bit of goop to ensure that
object identity is preserved -- that if A is passed from Python to
Objective-C and, later, Objective-C calls back into Python with A, it
is the same A as before (important for Strings and the like).
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden