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

Re: Objective-C from Dylan

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

> On Wednesday, December 13, 2000, at 01:15 AM, Andreas Bogk wrote:
> 
> > Rob Myers <robm@h2g2.com> writes: 
> >  
> > > Here's a toy program to call Objective-C from Gwydion Dylan code on MacOS
> > > X, written 
> > quickly last night. 
> >  
> > Interesting. Can you do the opposite? Receiving an Objective-C message 
> > in Dylan code? I understand that it is required to inherit from an 
> > application object in Cocoa. 
> 
> It's possible in principle:
> - Objective-C code compiles down to C functions and data structures.
> - The Objective-C runtime is implemented as C functions and data types.
> - The Objective-C messaging system is basically a series of hashtables of
> function pointers.
> - d2c and Fun-Dev can generate C callbacks to Dylan code which can be passed
> as function pointers.
> Therefore as long as we generate Objective-C method names/signatures
> correctly for hashing, we can add Dylan callbacks as function pointers in the
> Objective-C messaging tables using knowledge of runtime internals for a given
> Objective-C implementation. This will allow the Objective-C runtime to call
> Dylan methods, passing Objective-C messages into Dylan. 
> 
> [Further description of Obj-C/Dylan interface was here...]
>

How much do you know about the Java bridge to Cocoa, 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.

I've been hoping that a Dylan bridge for Cocoa could be created, and
would hopefully be a better fit than the Java bridge, which had to cut
some corners.

Thinking about the problem, one aspect of the Java bridge which I was
hoping could be improved on in Dylan is the treatment of parameters.
Objective C has named parameters, so you say:

[anobject DoThisMethodWithParam:x anotherParam:y yetAnother:z]

Since Java doesn't have named parameters, they have to do something
like:

anobject.DoThisMethod(x, y, z)

but since Dylan has keyword parameters, I was thinking a Dylan version
could do something more like:

DoThisMethod(anobject, Param: x, anotherParam: y, yetAnother: z)

or equivalently (to make the order closer to the Obj-C version):

anObject.DoThisMethod(Param: x, anotherParam: y, yetAnother: z)

making it much easier to read and relate to the Obj-C code than the
Java version.

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 presents a couple of questions. First of all, the keyword for the
first parameter is concatenated with the method name (or what is
conceptually the method name anyway) as in

[aView drawRect:myRect]

and this method is generally referred to as drawRect, not draw. Java
carries this over, so this becomes in Java:

aView.drawRect(myrect)

This could be done in Dylan too. On the other hand, I personally think
it would be more elegant to render this as:

aView.draw(Rect: myRect)

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

The second question is what to do when two selectors differ only in the
keyword used for some parameter after the first. 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). One example I found was in NSArray, which has two
methods with selectors dexcriptionWithLocale: and
descriptionWithLocale:Indent: .

I'd like to tell you how Java handles this situation, but I couldn't
find these methods in the Java NSArray documentation at all!

You could handle a Dylan to Obj-C call in this situaİion by having the
wrapper function dispatch two different Obj-C calls based on whether
the keyword is there. 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.

To get back to the general problem of a Dylan bridge, it looks to me
like a fruitful approach could be to start by looking at what Apple did
to create the Java bride. Copy that approach, but improve where
possible. Since Java is a less dynamic language than Obj-C, some
workarounds were required to be done that may not be necessary for
Dylan.

- Dennis D.