> I think it's smart to have done what you did.

Thanks. Now if I could only claim that to be my idea... ;-)

Cheers,
   - Andreas

Robert Withers wrote:
> 
> On Oct 16, 2006, at 8:42 PM, Andreas Raab wrote:
> 
>> Robert Withers wrote:
>>> Secondly, FarRefs and promises don't understand all the base protocol 
>>> that a normal object understands so many of the tools in the image 
>>> don't deal well with eventual objects.
>>
>> Actually, I consider this a fatal bug of FarRefs which I finally 
>> solved in the Croquet version (TFarRefs).
> 
> I think that's pretty smart.  My description of changing the primitives 
> to be eventual aware are intended to describe my concept of going the 
> other way and that means that any object could possibly be eventual.  
> Whether they are remote or not doesn't matter - it truly is a change in 
> the execution semantics of the VM and it's best to make that change 
> rather than doing what I was doing.  Of course, this doesn't address 
> issues that may arise due to latency or ordering which could still 
> affect all those tools.  I agree that you may still desire to be more 
> explicit when dealing with remote objects, but to my way of thinking 
> that is secondary to the idea of making the VM eventual.  Anyway, that 
> is how you would need to do it to get SqueakElib truly working in the 
> image.
> 
> I think it's smart to have done what you did.
> 
> Cheers,
> Robert
> 
>