Hi, first post, sorry for breaking any rules. ;-)
On Sat, Mar 27, 2010 at 6:17 PM, Marcus Denker <[email protected]> wrote: >> Perhaps we can be cleverer. What could we do if we introduced delegation >> into the language? Then we can add wrappers around objects and put the >> interception into the wrappers. This way there is no additional check. If >> one wants to intercept references to an object one creates a DNU wrapper and >> becomes the two objects. >> >> An execution model of delegation is that there are two slots for the >> receiver in a context, a state slot through which inst vars are accessed, >> and a self slot to which messages are sent. Normal sends merely duplicate >> the receiver into both slots. Delegating sends take state as an additional >> argument. >> >> An alternative model is to dispense with direct inst var access (assuming >> the JIT will inline simple accessors in PICs, or simply by virtue of the use >> of machine code render accessors affordable) and provide accessors for >> delegators that indirect through the delegate. >> > > Yes, that would be interesting to look at. I can offer a bunch of code and papers on such a system. Hans Schippers, Dirk Janssens (University Antwerpen, Belgium), Robert Hirschfeld and myself implemented a thing we called delMDSOC. It started out as a machine model for aspect-oriented programming but turned out to be much more interesting. It's been implemented using COLA. *All* requests to objects are messages in this model, including instance variable access. *Everything* is done using delegation. Also, the system implements what Eliot wrote above about two receiver slots for state and self. Stuff is available from here: http://www.hpi.uni-potsdam.de/swa/projects/delmdsoc The implementation is optimised as far as COLA goes. There is much potential for improvement, and implementing some PIC-like caching schemes failed because of some COLA shortcomings I could not figure out how to fix. Best, Michael _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
