On Oct 16, 2006, at 9:47 PM, Andreas Raab wrote:

> > I think it's smart to have done what you did.
>
> Thanks. Now if I could only claim that to be my idea... ;-)

ditto.  :-)  I can't recall where those ideas I expressed originated,  
perhaps yourself, but I was expressing them as opinions.

Cheers,
Robert

>
> 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
>
>