> Howard Stearns wrote:
>> What's the definition of "island discipline?"  I think it has  
>> something to do with no island (including the Island default)  
>> holding on to any long-lived references to something in another  
>> island.
>
> Really only that an object mustn't refer directly to objects in  
> other islands.
>
>>   - But there are exceptions that are allowed, such as classes.
>
> Unfortunately, yes. Couldn't make it work for the time being  
> without those :-(((
>
>>   - And I'm not sure what the limitations are on transiently held  
>> references. Empirically, I know that the execution of a future  
>> message from the Island default to another island can pass  
>> something on to the Island default (e.g., a CroquetEvent), but I  
>> imagine that the island better not store that reference such that  
>> it's still around when the island tries to sync.
>
> With proper future messaging this isn't a problem. A CroquetEvent  
> for example gets copied when it's passed into the island. So  
> storing isn't a problem at all. Generally, all objects get copied  
> when you pass them into an island unless you pass a reference to an  
> object inside that island. The only exceptions are classes (as you  
> noted above).
>
>> I don't know how to look at it right. Here's my thinking, but it  
>> would lead me to believe that snapshots would reliably fail all  
>> the time, which they don't:
>>    The snapshot trace (below) shows that when the event holds the  
>> camera, then the Island default (outside) has a reference to the  
>> camera. OK, that's fair.  And it shows that the island being  
>> sync'ed has created a TFarRef to the camera.  Thus the island  
>> (inside) and the outside both reference the camera. Bad.  I think  
>> the reason the island makes a TFarRef to the camera is that event  
>> handlers like #pointerDown: pass the CroquetEvent, which is  
>> passByClone:, and so it tries to pass the camera in turn. Since  
>> the camera is passByProxy:, it creates a TFarRef.
>
> Yes, but this wouldn't apply in the case of a future message. Your  
> analysis makes sense in the situation that the event is used in a  
> synchronous send; but I'm not sure where this would happen. Here is  
> something to try: Change TCamera class>>howToPassAsArgument to  
> something that will raise an error when you try to execute it (say  
> #passByFoo:) to see where exactly that reference is created.
>
> Cheers,
>   - Andreas
>