Hi Mathieu,
> So if I understand correctly what you suggest is that > Instead of calling directly LKSendMessage I have function that for each > parameter it wrap it in a Objective-C proxy. > And that the Objective-C proxy implement forwardInvocation: so that each > message > send to the objectiv-c proxy is being forward to the smalltalk object? Yes, more or less. The only things that are receiving messages are objects. You currently have some kind of shim that looks strange. Rather than being a simple proxy, it is an object that contains a reference to an Objective-C object and implements a method that sends a message to the Objective-C object. This is a weird way to do things, and will be horrible to use, both for people familiar with Objective-C and people familiar with Smalltalk. Programmers expect to have objects and send them messages, without thinking about whether they are really implemented in Smalltalk or Objective-C. Because you have two object models, you need to provide a mechanism for translating a Smalltalk message into an Objective-C message, and vice versa. The simplest way of doing this is via proxies (this is not fast, and wastes some memory, but it's simple). When you send a message to an Objective-C object from Smalltalk, you write something like: obj msg: arg. The receiver (obj) will be a proxy written in Smalltalk. This will not implement #msg:, so it will receive a #doesNotUnderstand: message. It should then: 1) Create an Objective-C proxy for arg. 2) Translate #msg: into an Objective-C selector 3) Call LKMessageSend (or equivalent) with the translated arguments LKMessageSend() will then handle the translation into C types for you, by looking up the types in the (real) receiver's method metadata and then calling methods like -intValue to unbox things. You may want to add a special case here for Smallnts (there's one in the compiler in LK), so that you don't need to wrap them, you just convert them directly). When LKMessageSend sends -intValue to the proxy wrapping arg, it will then be forwarded to some Smalltalk code, using the C-calling-Smalltalk interface in GST. This will return a C integer (or, more likely, a Smalltalk SmallInt that something then translates to a C integer, either the GST bridging code or your own code). Alternatively, you can move this unboxing logic entirely into Smalltalk. In this case, you won't call LKMessageSend at all - you'll use the existing GST Smalltalk-calling-C code to translate the arguments into C types (adding code for wrapping things that are expected to be objects in proxies) and then call the IMP directly. David _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
