Robert
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 are?
Thanks,
Robert Gottlieb
rcgottlieb@dclink.com
---------- From: Marcel Weiher[SMTP:marcel@system.de] Sent: Thursday, January 07, 1999 12:15 AM To: squeak@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@200 extent: 300@100) styleMask:15 backing:0 defer:0. 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 styleMask:15 backing:0 defer:0]; 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 modifications)
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.
Marcel
squeak-dev@lists.squeakfoundation.org