Future Objects


        http://www.yourworldoftext.com/FileObjects


        NicoleWillson

from http://www.merlintec.com/old-self-interest/msg00676.html'''

.... The notion of active vs. passive objects has proved to be an advantage in our project because the application developers are shielded from low level process/semaphore/queue related synchronization issues and can work on the a higher abstraction level provided by asynchronous/synchronous/future and balking message passing sematics.

- Is there any attempt to bring the notion of active/passive objects, and multiple message passing sematics into self ?

I am working on it, but I don't think it will be ready in time to be of use to you. My ( mythical ) TinySelf interpreter has only active objects. Every message send returns a future object immediately as the result, while the message gets queued at the receiver for later processing ( if it is already doing something else, each object executes a single method at a time ). If you try to send a message to the future object, however, you block. When the receiver finishes executing the message and returns the real answer, the future "become:"s that answer and unblocks any waiting objects ( threads ). In code like "x mess1 + y mess2", mess1 will block while mess2 won't ( it will inside the + method, of course, but that doesn't matter here ).
So messages are synchronous or asynchronous depending on how they are used, no matter what the sender or the receiver. This might prove to be *too* simple for serious applications, but I hope it will be enough. Of course, the way I have described it so far this model would make recursive methods deadlock and an object like the number 2 would be a serious bottleneck in the system. But I won't go into these details here.

- Is it considered to be a good idea to build these features into the language or should they always be provided by an add on system (if so, things like the CLOS "around/before/after" functions are useful and make the doesNotUnderstand trick obsolete in certain cases).

In some systems this might be done using some metaobject protocol, but I feel that Self's "message passing at the bottom" approach makes it better to have a built-in concurrency model.
Regards,
- -- Jecel Mattos de Assumpcao Jr
- Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil -- jecel@lsi.usp.br
- http://www.lsi.usp.br/~jecel/jecel.html