Re: Objective C bridge (Long)

To: info-dylan@ai.mit.edu
Subject: Re: Objective C bridge (Long)
From: Rob Myers <robm@tdv.com>
Date: Mon, 12 Mar 2001 18:10:02 +0000
Sender: owner-info-dylan@ai.mit.edu

On Monday, March 12, 2001, at 05:45 PM, Dustin Voss wrote:

> Hmmm. I wouldn't expect Dylan to interact with Obj C's memory or data  
> structures at all. 

It will need to in order to introduce its classes and methods, and to coerce objects.

> When an Obj C object is finally freed, the runtime calls - dealloc. I  
> can override that to call a Dylan method that will free the Dylan  
> reference to the bridge class. 

Yes, that sounds good. If Boehm is too keen to deallocate objects that Objective-C references but Dylan doesn't then init can put the Dylan object into a hashtable.

> When I create the Obj C stub class, I can specify an existing Obj C  
> class to be the superclass. The stub won't need to pose. The Dylan stub  
> class won't need to interact with anything but the Obj C superclass --  
> even native Obj C classes don't have that capability. Dylan methods can  
> call a super's method by sending a message to the Obj C stub's super. 

Agreed. I learnt a lot writing that code. :-)

> I think we can get away without creating a parallel hierarchy. Remember  
> that the Java/Obj C bridge is meant to be a two-way bridge, but this  
> isn't. That lets us cut corners. 

Being able to directly subclass Objective-C objects means there's no need for a paralell hierachy, yes.


> > View will be the hidden this parameter, and between that and rect there's  
> > a hidden sel parameter. The Java bridge automatically converts Strings  
> > and other much-used types. The Dylan bridge should definitely do this,  
> > although an <NSString> subclass of <string> should work well. 
>  
> That's a good idea. Better than converting from a <string> each time. 

If <NSString> is a subclass of <string>, the caller won't even need to know.

> I thought about that. The advantage of declaring the class and then  
> declaring the bridge is that the class itself won't carry any excess  
> baggage, other than the inherited <obj-c-bridge> slots. But that might  
> backfire. I probably should combine the two. 

The syntax will be cleaner keeping them separate, on reflection.

> That code you posted should help with this. What do you mean by  
> "signature string"? Something like "alloc:withFrame:"? 

In the runtime, we need "alloc:withFrame" (the selector) and "@4@4@4*r8" (the types) for that method. The former can actually be the name of the Dylan method, which a macro can extract. The latter is a pain to generate by hand, and again a macro can generate it if the input to the macro is formatted well. 

- Rob.


--
Rob Myers - http://www.robmyers.org/dylan
Advanced Free Software Development Tools -
http://www.gwydiondylan.org/