Object pointers

Rob Withers rwithers12 at attbi.com
Sun Mar 24 21:46:34 UTC 2002


Alan Kay <Alan.Kay at squeakland.org> wrote:
> It's "just like" LISP -- from which it got these sharing ideas long 
> ago in the 60s (even before Xerox PARC Smalltalk). OOPs are simple 
> views of an object (they "show" the entire object).

Hi Alan,

Does LISP or other systems have a history of using less simple views on
an object?  I am researching the impact of extending message sending
semantics to include an eventual-send->promise->resolve style.  Do you
think it will be difficult to intuitively interact with objects that
don't return values immediately?  It is sometimes, especially with
inspectors which expect strings back *now*. :)  Aside from those issues,
I am exploring the feeling of interacting in that kind of sending
environment.  Would it behave in a way that users expect?  A related
meta-question I have, is what features are required for interaction to
be intuitive?

I'll attempt to briefly and clearly explain eventual sending.  Please
excuse me if I fail at that task.

I am building the promise-based eventual send mechanism of Elib, in
Squeak (http://www.erights.org/elib and especially
http://www.erights.org/elib/concurrency/msg-passing.html).  This extends
the immediate-call->return style of squeak message-sending to an
eventual-send->promise->resolve style of message sending.  Eventually
sent messages are not executed immediately.  This type of eventual
reference returns an object reference, as a promise, to which you can
eventually send additional messages, each returning a new promise
reference. 

These messages, sent to the promise reference, are pending until the
receiver promise resolves to a real object reference (#become:), then
the messages are eventually forwarded to this resolved object, and in
turn each of their promises resolve, und so weiter.  It is remarkable to
me that separating the message sending from the method execution,
results in small sequences of pending messages queued for those promise
resolved objects.  

These eventual references (objects or promises) are currenly
compromised, as there are a few areas in squeak where the environment
expects immediate values returned.

generally speaking, thank you for the opportunity. :)
Rob

> Cheers,
> 
> Alan



More information about the Squeak-dev mailing list