> Send site descriptors (that have been discussed here on several > occasions) can solve many of the internal ABI problems, but by no means > all of them. However, I think they would be sufficient for Leiberman > prototypes provided 'receiver self' was communicated to the destination > method exclusively through the descriptor and the descriptor was made > available to, and could be extended from within, lookup. >
Is now the time to reify messages as objects to support "message send" protocol extension? Create a message object on the stack in sendv(); but where to define the send(): on the message, receiver or a system object? I avoided recursion in MOS by bootstrapping lookup() and apply() on a pair of well-known meta-objects. What would be destroyed by adding a _meta slot in vtable? Use Marcus' meta-context technique to avoid recursion? Message objects could be created with a bootstrapping vtable known to implement a baseline send() meta-protocol. But is the receiver or the system implementing the "message send" meta-protocol? There is no MOP, only vtables, object, selectors and methods. system.send(message), message.send(), message.receiver.send(message) or a decompositon using all three to allow granularity? Elide message object creation if standard send() protocol is in effect. (This could be somewhat interesting to attempt in libid. :) The former appears to lend itself toward Marcus' meta-context, the later lends itself to proxying, tracing, etc. If one wants to introduce a low-level MOP, perhaps it should be orthogonal, expressly opposite of many reflection protocols are in many languages: "there can only be one reflection/MOP/serialization protocol". The question is: if one wants to dynamically change the vtable (or clone family) selected in _sendv() for the message object, how do one do so? By what protocol? Marcus's meta-context? Perhaps, simply avoid it all by making [message.addMethod: @send ...] a special case that also saves the send() method into a global function pointer in libid. At what point does libid disappear in the tool chain? Is the extension (or substitution) of send() only to be a privilege and destination of tools up the chain? Or should higher levels be allowed to reify send() at lower levels? Sorry, my reply had way too many questions. Where is the message itself? :) > Cheers, > Ian > Kurt _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
