Squeak/Objective-C bridge update (long)

John Clarke clarkej at cuug.ab.ca
Wed Jan 13 00:00:21 UTC 1999


Perhaps you're referring to Marcel's post, included below:

Robert wrote:

[ snip ]

Also, I vaguely remember a post about Objective-C.  Could the author please
resend it to me, or someone tell me where the archives of this mailing list


Robert Gottlieb

rcgottlieb at dclink.com

From: 	Marcel Weiher[SMTP:marcel at system.de]
Sent: 	Thursday, January 07, 1999 12:15 AM
To: 	squeak at cs.uiuc.edu
Subject: 	Squeak/Objective-C bridge update (long)

Hi Folks,

a very rudimentary Squeak/Objective-C has been completed, it allows  
the execution of code like the following:

| nswindow |

nswindow _ ObjCProxy proxyWithClass:'NSWindow'.	
TestWindow _ nswindow alloc initWithContentRect:(200 at 200 extent: 300 at 100)
TestWindow makeKeyAndOrderFront:nil.

NSWindow is a native Objective-C class, all the messages sent to it  
are native Objective-C messages, the (roughly) equivalent Objective-C  
code is as follows:

   NSRect contentRect = { 200,200,300,100 };
   id testWindow;

   testWindow = [[NSWindow alloc] initWithContentRect:contentRect
   testWindow makeKeyAndOrderFront:nil];

To do:

  - proxy memory management (gc/refcount, uniquing, image save/restore)
  - call-backs (probably have to use co-routines)
  - possibly better marshalling scheme ( currently ASCII encoded )

I would be grateful for help (pointers/code/tips) on any of these topics.

Some observations and ideas:

This type of native interface contains the potential for applying  
the 'implemented in itself' idea even more broadly than at present,  
by having native code look almost completely like Squeak code.

1.  Primitive I/O as 'remote object'

Primitive I/O can be made to look just like a set of objects  
providing I/O services.  With the native boundary not really visible  
any longer, it should be much easier to have it located at different  
levels for different ports (native blitting -> native windowing ->  
native widgets ).  Additionally, headless systems could have an I/O  
interface that really is a remote-object interface instead of just  
looking like one.

2.  Proxy-less integration

It is possible to eliminate the need for proxies, allowing  
Objective-C objects  to be messaged directly from Squeak and vice  
versa.  Squeak and Objective-C could both access instance variables  
because the object models are compatible.  (the interpretation of the  
low 2 bits of the first word of an object would have to be modified  
slightly and both the Squeak and Objective-C messagers need some easy  

3.  Easier C-code generation + writing

The Smalltalk dialect used to write primitives could be easily  
brought much closer to full Smalltalk, allowing both direct instance  
variable access and messaging.  This could also be extended to the  
interpreter itself without compromising the ability to be compiled by  
a plain C compiler.


More information about the Squeak-dev mailing list