[Prev][Next][Index][Thread]
Re: Objective-C from Dylan
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?
Can Objective-C classes be made dynamically?
> There are some potential problems, though. Objective C really considers
> the parameter names part of the selector name, so the selector of the
> method described above is
> DoThisMethodWithParam:anotherParam:yetAnother:
This isn't a problem. The selectors will be represented as symbols which can be whacked to strings and concatenated using the Dylan macro system. Or the actual call signature can be generated and stored as a string when the Dylan wrapper is generated.
> ...but to do this for all of the thousands of Cocoa methods could cause
> confusion when reading something using Objective C (or Java) code and
> trying to figure out what this would be in Dylan. It might be more
> prudent to carry over the convention of embedding the first parameter
> keyword in the function name to maintain consistency.
Yes, we should keep things consistent with standard Objective-C usage.
> The second question is what to do when two selectors differ only in the
> keyword used for some parameter after the first.
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. :-)
> This doesn't seem to be a common situation in Cocoa (variations in the first parameter
> keyword are _very_ common, another good reason to keep it embedded in
> the function name).
This is fortunate for the reason given above.
> The issue I'm worried about is what happens if
> you want to override one of these selectors in a subclass if more than
> one Obj-C selector maps to the same Dylan function. It seems like this
> is likely to be so rare, though, that it could be handled on an ad-hoc
> basis.
Yes.
- Rob.