Object pointers (+ a de-ENH, and a crash)
mgomes21 at cox.net
Fri Apr 12 04:33:39 UTC 2002
> Sorry for the late reply. I returned from Europe, this week, to find I
> had Cable modem issues. I posted an implementation of what I discuss
> above at http://minnow.cc.gatech.edu/squeak/2410.
My only excuse is that it took me this long to think about the issue. I
need to give my eyes some time to uncross.
> You called this object of yours, silly, in the sense that it was
> changing state underneath you. Thanks to your work, mine doesn't change
> identity now, so I will try to claim that if it's identity doesn't
> change, then the processing of messages to it should be predictable to
I consider it silly because I am only following my aesthetic sense in
making it. I have no practical project to actually use and test it in.
Experiencewise, I still believe that new object instances are delivered by
a stork ;) .
> In your example, you have a promise to a string, and you send it string
> protocol messages. To me, it seems as if this object were never there.
That is an awful example that I gave. I would have been better off
bogo-sorting something, and demonstrating that the pain is postponed.
> Is this what you think silly about it? If it's predictable in this
> synchronous setting, it should be in an asynchronously sending
> environment and that is where the promise can start working for us. Do
> you think interaction with asynchronous references is intuitive?
By unpredictable, you mean that the message chain is already halfway
worked through when the promise is called upon for a final answer, right?
I have no opinion on async refs.
> Having thought about the question some more.. #becomeForward: must be
> slower than my #primSwitchRedirector:toContext:, since it has to do a
becomeForward: may not be quite as catastrophic as you think. I started a
small thread about (almost) this, "Why can't I do (aNonSmallInteger
becomeFoward: aSmallInteger)". According to Tim Rowledge, identity swap is
done in a trickier, less memory thrashing method than a full GC. My
current belief is that these "fowarding blocks" that ObjectMemory mentions
provide an extra indirection until the next GC fixes things up.
> My code uses a MessageRedirectorProxy, which defers all message sends to
> it's context object. The promise context will mutate into a near or
> broken context when the promise is resolved. At this point, I believe
> your object could fit here nicely. For it to block until asynchronously
> resolving the promise, you could have the block call a monitor, which
> could block until the task which was promised, resolves. This could be
> done by a Future object (which is called a Promise in VW). My
> implementation looks like:
Feel free to take anything you find useful, it will probably be purged by
the next version.
The new and EEMPROOVED LazyObject now lives at
http://minnow.cc.gatech.edu/squeak/2421. This time it actually supports
(gasp) explicit message queueing. I recently found that the coolest
message to enqueue is #in:.
"You know how to whistle, don't you? Just put your lips together and
- MS tech support in "Patlabor"
More information about the Squeak-dev