[Prev][Next][Index][Thread]
Re: Objective-C from Dylan
"Dennis C. De Mars" wrote:
>
> Unfortunately, the only documentation I know of is the "Java Bridge"
> document at Apple's Mac OS X documentation site (which you are probably
> already aware of),
Shamefully, I wasn't. I've read through it now and I think I see how
they're doing it.
A tool to allow Dylan code to be callable from Objective-C would:
- Parse an interface file describing which Dylan class and methods
belong to which Objective-C classes.
- Parse the Dylan sources for method signatures.
- Generate a .dylan file of c callbacks for the Dylan methods.
- Generate .h files for NSProxy subclasses for the classes.
- Generate .m files for the Objective-C classes, implementing
respondsToSelector: and forwardMessage:
This seems to be how the Java/Objective-C bridge works. Adding an
<NSString> class that can as( <string>, nsstring-sinstance) would make
things much easier, this is called "morphing" in the J/O-C bridge.
If just declaring NSProxies doesn't work, the Objective-C classes could
be given other superclasses. These (and protocols) would be declared in
the interface file.
Dylan callbacks from Objective-C would need to have the correct
parameter list, taking the hidden parameters. This might be macro-able.
Would such a tool be called "doc"? :-)
> > Making the call out to Obejctive-C isn't a problem, as we can generate
> > arbitary method signatures and call them. Making the call wrapper in Dylan
> > differ only on keywords would be more difficult. Dylan requires that keyword
> > parameter lists for a method be congruent unless the method accepts an
> > #all-keys parameter (which takes all the keyword params). Therefore a Dylan
> > wrapper for an Objective-C method with differing non-first parameters would
> > have to check to see which keys it got then dispatch on that.
> > Hopefully someone can tell me I'm wrong and the situation is a lot simpler.
> > :-)
>
> Yes, I was assuming that is the way you'd have to handle it. It seems
> like you'd be taking an efficiencly hit with this technique, as you'd
> have to explicitly examine the keyword list before dispatching the
> correct method. However, since the situation seems to be rare in the
> Cocoa API (for the second, third etc. parameters that is) thix probably
> isn't a big issue.
If it's rare enough, that's fine.
- Rob.
--
Rob Myers - http://www.robmyers.org/ H2G2 - http://www.h2g2.com/
MacOS wonderfulness for The Hitch Hiker's Guide to the Galaxy Game.
"Smash Global Capitalism! Spend less money!"
References: