Hi Josh,

thank you very much for your kind message and the insightful comments!  
This line of your post I admire most:

>
> Yes, definitely.  If it is easy to cheat, then developers will cheat.
>

As emailed to Igor a minute ago, he+me managed to mix up CorruptVM with  
SqueakVM in this thread and, from a comment that I've seen in another  
response, the concept of Island.

Take my apologies and, thanks again. If something comes out from the email  
discussion that I suggested to Igor then I'll summarize and post.

/Klaus

On Mon, 07 Jul 2008 19:32:59 +0200, Joshua Gargus wrote:

> On Jul 7, 2008, at 7:07 AM, Klaus D. Witzel wrote:
>
>> On Mon, 07 Jul 2008 14:38:21 +0200, Igor Stasenko wrote:
>>
>>> 2008/7/7 Klaus D. Witzel:
>>>> [sorry for cutting multiple Re's from the subject line]
>>>>
>>>> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
>> [...]
>>>>>>> I have some ideas of using Island/Vat model in future CorruptVM  
>>>>>>> project.
>>>>>>>
>>>>>>> I'm not going into deep detail right now, but the essence of model  
>>>>>>> is
>>>>>>> following:
>>>>>>>
>>>>>>> - an Island is the group of objects sharing same memory region.
>>>>>>
>>>>>> s/memory region/owner/ where owner can be sort of "deputy" of  
>>>>>> memory/VM
>>>>>> monitor. A very interesting concept indeed, thanks for posting :)
>>>>>>
>>>>>> I think that can be addressed with a small trick in Squeak's VM and  
>>>>>> *no*
>>>>>> extra object header (using one of the Metaclass ideas that Alex+my
>>>>>> discussed in Bern for Goya => coloring of metaclass instances).
>>>>>>
>>>>>
>>>>> Yes, there is no need in having extra state which indicates to which
>>>>> island belongs object.
>>>>> It is impossible by design to get direct reference to any object  
>>>>> which
>>>>> not belongs to same island.
>>>>
>>>> I think that, "ref to any object" can be restricted to "any  
>>>> receiver", just
>>>> so when sending something. When not sending something (=> when just  
>>>> peeking
>>>> and poking oops) then belonging to some island is of not so much  
>>>> importance
>>>> (this "receiver detail" is why I suggested s/memory region/owner/).
>>>>
>>>> You agree? Of course the "any receiver" detail is relative to  
>>>> SqueakVM;
>>>> CorruptVM's mileage may vary.
>>>>
>>> of course, a difference lies only in a way how we sending message to
>>> object, wrapped by FarRef.
>>
>> I think that the main difference we have here is induced by your "it is  
>> impossible by design to get direct reference to any object which not  
>> belongs to same island." which I take literally (without objection, to  
>> be clear). As a consequence, when running "in island #1" you cannot do
>>
>> proxy := anIsland2Object asFarRef.
>
> Of course not... you can't have a direct-ref to anIsland2Object in the  
> first place.
>
>> instead you must do
>>
>> proxy := FarRef with: anIsland2Object.
>>
>
> Nope, can't do that either (for the same reason).
>
> To create an island in the first place, you evaluate
>
> 	anIsland := Island new.
>
> This doesn't give you a direct-ref to the island; it gives you a far-ref  
> to it.
>
> You can instantiate a new object on the island by sending #new: to the  
> island.
>
> 	aMorph := anIsland new: Morph.
>
> Of course, this gives you a far-ref to the newly created morph.  If you  
> send messages to this object, the answered object is also wrapped (for  
> most objects anyway; some types of objects are copied).
>
> 	subMorph := anIsland new: EllipseMorph.
> 	aMorph addMorph: subMorph.
> 	subMorph owner.              "a FarRef to aMorph"
> 	aMorph submorphs.         "an Array of FarRefs to Morphs"
> 	aMorph position.                "a Point (a copy of the on-island  
> Point)"
>
>
>> and moreover [on a sideline, not so important] one cannot ask to which  
>> island *any* far (but as-yet-not-wrapped) object belongs.
>>
>
> Every process is associated with an island, so any unwrapped object is  
> associated with the island of the currently running process.
>
>> Therefore I thought that sending something to a far (but as-yet-not- 
>> wrapped) object is like a DNU which the VM detects and automatically  
>> wraps into a FarMessageSend.
>
> In terms of Tweak and Croquet, Tweak FarRefs do work by using DNU.   
> Croquet TFarRefs require an explicit #future message to be sent to a  
> far-ref.  For example, the above would look something like (neglecting  
> how to connect to a Croquet router):
>
> 	anIsland := TIsland new.
> 	aMorph := anIsland future new: Morph.
> 	subMorph := anIsland future new: EllipseMorph.
> 	aMorph future addMorph: subMorph.
> 	subMorph future owner.              "a FarRef to aMorph"
> 	aMorph future submorphs.         "an Array of FarRefs to Morphs"
> 	aMorph future position.                "a Point (a copy of the on- 
> island Point)"
>
> The original implementation had #future return a proxy object.  In the  
> current implementation, #future is a keyword that is handled specially  
> by the Compiler.  It's a bit more verbose, but on the other hand, all  
> #future messages to a TFarRef result in network traffic, so being  
> explicit makes it easier to keep track of what is going over the wire.
>
>> I think this is quite a difference to systems which would be based on  
>> manually wrapping (developer-driven-wrapping DDW), in which the  
>> impossibly to obtain a direct reference would be left to the developer  
>> (and/or her/his bugs).
>
> Yes, definitely.  If it is easy to cheat, then developers will cheat.
>
>>>>> For referencing objects from different island there will be a FarRef,
>>>>> which will be responsible for handling message sends to object in
>>>>> different island.
>>>>
>>>> Hah :) a natural extension of the #doesNotUnderstand: concept (with
>>>> FarMessageSend a subclass of MessageSend :)
>>>>
>>> Nah!
>>> You don't need to use DNU pattern,
>>
>> See above, not having sort of DNU can easily contradict your "it is  
>> impossible by design to get direct reference to any object which not  
>> belongs to same island". Somehow every *failure* to *not* get a direct  
>> reference must be detected and acted upon (note the negations).
>>
>
> As described above, DNU is one way (but not the only way) to do this.
>
> Cheers,
> Josh
>
>
>> ---------------
>>
>> If you like we can go into more detail in email (also addressing #new  
>> instances and their belonging to an owner).
>>
>>> since you free to change a message
>>> sending semantics for FarRef.
>>> In this way, FarRef will act as transparent proxy, and ALL messages to
>>> it will lead to sending message to wrapped object which is located in
>>> different island.
>>>
>>> A FarRef could reserve a special selector for itself, like
>>> #performLocal: selector withArguments: args
>>> to send message to a FarRef object, not to wrapped object.
>>>
>>
>>
>
>
>