• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Toll-free bridge type at runtime
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Toll-free bridge type at runtime


  • Subject: Re: Toll-free bridge type at runtime
  • From: Bill Bumgarner <email@hidden>
  • Date: Thu, 02 Apr 2009 22:47:12 -0700

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. ;)


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?

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.

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.

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

_______________________________________________

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


  • Follow-Ups:
    • Re: Toll-free bridge type at runtime
      • From: Ryan Joseph <email@hidden>
References: 
 >Re: Toll-free bridge type at runtime (From: Greg Guerin <email@hidden>)
 >Re: Toll-free bridge type at runtime (From: Ali Ozer <email@hidden>)
 >Re: Toll-free bridge type at runtime (From: Ryan Joseph <email@hidden>)
 >Re: Toll-free bridge type at runtime (From: Chris Hanson <email@hidden>)
 >Re: Toll-free bridge type at runtime (From: Ryan Joseph <email@hidden>)

  • Prev by Date: Re: Toll-free bridge type at runtime
  • Next by Date: Re: Toll-free bridge type at runtime
  • Previous by thread: Re: Toll-free bridge type at runtime
  • Next by thread: Re: Toll-free bridge type at runtime
  • Index(es):
    • Date
    • Thread