Bert,
My reverse engineering study is, of course, not a conclusive analysis of 
Islands as such. It is merely a snapshot of a particular instance of an 
island with an operation or two + an evaluation of its suitability as a 
foundation for my work with BabyComponents.

I see that my statement about 'free floating objects' has been interpreted 
in a way that makes it false and I apologise for not being sufficiently clear.

My point is that island membership depends on the island of the current 
process; it depends neither on any feature of the object itself nor on a 
feature of the Island object. In fact, membership is a dynamic property:
    Object>>island
       "Answer the receiver's island"
       ^Processor activeIsland
Processor is a global variable, an instance of ProcessorScheduler.
    ProcessorScheduler>>activeIsland
       "Answer the currently active Island."
       ^activeProcess island ifNil:[Island default]
and
    Process>>island
       "Answer the receiver's island"
       ^island
Deep down, an object is on the island that is currently stored in 
activeProcess. It is not a static feature of the object itself. A second 
point is that I haven't found any way for finding all objects on an island.

I find the first comment misleading. The second is correct; the method 
returns the currently active Island. The third is also correct because the 
receiver now is the activeProcess.

In my report, I chose what I thought was a simple way to illustrate this 
dynamic nature of island membership. Here are three other ways:

(1)
Start from the inspector shown, inspect innerObject. You get a FarRef. 
Select and inspect myValue. You get an inspector on the inner object. In 
this third inspector type and print 'self island' in the bottom pane. The 
result is that the inner object is on  the Squeak island.

(2)
Add this method:
     IslandServerInner>>initialize
         super initialize.
         Smalltalk at: #INNER put: self.
Run
    'IslandClient new test'
and then evaluate
    '(Smalltalk at:#INNER) island. '
The answer is again the Squeak island.

(3)
Execute
    IslandServerInner allInstances collect: [:inner | inner island]
and get:
    #(an Island(Squeak) an Island(Squeak) an Island(Squeak) an Island(Squeak))
I have clearly the results of several test runs sitting in my image. The 
four inner objects have all been created on an IslandServer. Nevertheless, 
all here appear to reside on the Squeak island. (I expect they will still 
be on an IslandsServer if approached correctly.)

It seems to me that the Islands philosophy is to maintain an island's 
member objects by strict border control. The objects are not floating free 
-- as long as all accesses pass through the border control. I have, in a 
sense, been observing the member objects from above through regular Squeak 
Inspectors and the BabyRE reverse engineering interface. I circumvent the 
border control, and the objects appear to be floating freely. Two 
perspectives, two results.


I do not criticise the Islands vision or implementation. I have found 
nothing wrong with it apart from the few comments that confused me. I 
definitely see it as a valuable contribution. I initially believed it to be 
closer to my vision of a BabyComponent than it turned out to be, but that's 
my problem and does not reflect on the Islands package as such.

Keep up the good work!
--Trygve


At 18:07 23.09.2005, you wrote:
>Am 23.09.2005 um 14:53 schrieb Trygve Reenskaug:
>
>>My reverse engineering of Islands may be of interest to others. I
>>found the objects, their links, and their interaction pattern for a
>>few interesting operations. The report is at
>>   http://heim.ifi.uio.no/~trygver/2005/babyuml/tweakComponents.pdf
>
>Note, however, that this is not a conclusive analysis of Tweak
>Islands. In particular, this statement is false  (as I explained in a
>private message before):
>
>     "The objects themselves are floating freely and their island
>property depends on the island of the
>observer. The two last print it statements in figure 3 on page2  show
>that the same object appear to reside
>on two different islands simultaneously."
>
>This is wrong. Objects live on one and only one island (unless there
>are bugs etc.).
>
>By using the #instVarAt: method you are actively circumventing the
>Island encapsulation. This method was implemented in FarRef in
>particular to aid debugging.
>
>In your test, innerObject is a FarRef to an IslandServerInner:
>
>     innerObject "Far serverIsland:[an IslandServerInner]"
>     innerObject island "Far serverIsland:[an Island(serverIsland)]"
>     innerObject asString  'an IslandServerInner'
>
>By calling
>
>     innerObject instVarAt: 2 "an IslandServerInner"
>     (innerObject instVarAt: 2) island "an Island(Squeak)"
>
>you directly extract the value of the FarRef and thereby "tunnel" the
>far object onto the current Island. When asking it for its #island
>later, it of course answers the calling island.
>
>Without the debugging aids it would be impossible to directly access
>objects on another island. Which would make debugging itself next to
>impossible.
>
>- Bert -
>


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050924/fc3b6214/attachment.htm