Re: Toll-free bridge type at runtime
Re: Toll-free bridge type at runtime
- Subject: Re: Toll-free bridge type at runtime
- From: Ryan Joseph <email@hidden>
- Date: Fri, 3 Apr 2009 14:22:10 +0700
On Apr 3, 2009, at 12:47 PM, Bill Bumgarner wrote:
On Apr 2, 2009, at 8:40 PM, Ryan Joseph wrote:
// We must use the "Handle" which is the Objective-C object because
dragTypes is a NSArray wrapper and passing a Pascal object to
Objective-C runtime WILL cause errors
dragTypes := NSArray.array_;
view.registerForDraggedTypes(dragTypes.Handle);
I just didn't want users to type .Handle and let that choice be
made a runtime behind the scenes. Was that worth everyones time? ;)
If it is what was required to lead to this point, then ... yes... it
was an unfortunate use of time but ultimately led to this rather
important detail that probably should have been posted in the first
place. ;)
In retrospect for sure. ;) At first I thought it would just be an
extra detail to confuse people.
So -- you aren't actually building a transparent bridge. You are
effectively building a solution that proxies objects between one
side and the other and, on the Pascal side (at the least), the users
of your proxying bridge have to take an extra step to gain access to
the underlying object.
It is certainly a valid way to build a bridge between the
languages. But is the extra level of indirection really necessary?
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.
Thanks for your ideas.
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.
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.
Regardless, there is a tremendous body of work available that
successfully demonstrates bridging between Objective-C and other
languages. Much of it is under extremely liberal license -- PyObjC
is MIT Licensed, feel free to copy/paste at will -- and it would
likely be a boon to you to explore such implementations deeply?
b.bum
Regards,
Josef
_______________________________________________
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