[Prev][Next][Index][Thread]

Re: Objective-C from Dylan

In article <200012131950.OAA22693@life.ai.mit.edu>, Rob Myers
<robm@onetel.net.uk> wrote:

> On Wednesday, December 13, 2000, at 06:30 PM, Dennis C. De Mars wrote:
> 
> > How much do you know about the Java bridge to Cocoa, 
> 
> Not a lot, I'm afraid. I am very familiar with the Java runtime and know a
> little about the d2c and Objective-C ones.
> 
> > and how much of  that technique could be applied to a Dylan bridge? Your
> > description of 
> > creating proxy objects in Obj-C to stand for the Dylan object sounds 
> > similar to the way they are doing it for Java. 
> 
> If you have any public references about how Apple did the Java bridge I'd
> really like to see them. Do you have any URLs?

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), and that only talks in very general terms about how
the Java bridge was implemented (although it is still worth reading as
a starting point by anyone interested in the problem of createing a
bridge for another language). I wonder if Apple might provide more info
to someone interested in doing a similar bridge for Dylan?

> Can Objective-C classes be made dynamically?

Not as far as I know; you can send messages to classes but I don't
think you can actually create a new class at run time as you can in
Dylan. I think you _can_ do things like get the class given a string
that is determined at run time, but the class would have to already
been defined at compile time.

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

- Dennis D.
Follow-Ups: