<html>
<body>
Bert,<br>
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.<br><br>
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.<br><br>
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:
<br>
<b>Object>>island <br>
</b> <i>"Answer the receiver's
island"<br>
</i> ^Processor activeIsland<br>
<i>Processor </i>is a global variable, an instance of
<i>ProcessorScheduler</i>. <br>
<b>ProcessorScheduler>>activeIsland<br>
</b> <i>"Answer the currently active
Island."<br>
</i> ^activeProcess island ifNil:[Island
default]<br>
and<br>
<b>Process>>island<br>
</b> <i>"Answer the receiver's
island"<br>
</i> ^island<br>
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.<br><br>
I find the first comment misleading. The second is correct; the method
returns the <i>currently active Island</i>. The third is also correct
because the receiver now is the <i>activeProcess</i>. <br><br>
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:<br><br>
(1)<br>
Start from the inspector shown, inspect <i>innerObject</i>. You get a
<i>FarRef</i>. Select and inspect <i>myValue</i>. You get an inspector on
the inner object. In this third inspector type and print '<b>self
island</b>' in the bottom pane. The result is that the inner object is
on the<i> Squeak </i>island. <br><br>
(2)<br>
Add this method: <br>
<b>IslandServerInner>>initialize<br>
</b><x-tab> </x-tab>super
initialize.<br>
<x-tab> </x-tab>Smalltalk
at: #INNER put: self.<br>
Run <br>
'<b>IslandClient new test</b>' <br>
and then evaluate <br>
'<b>(Smalltalk at:#INNER) island.</b> '<br>
The answer is again the <i>Squeak </i>island.<br><br>
(3)<br>
Execute<br>
<b>IslandServerInner allInstances collect: [:inner | inner
island]<br>
</b>and get:<br>
<i>#(an Island(Squeak) an Island(Squeak) an Island(Squeak)
an Island(Squeak))<br>
</i>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 <i>Squeak </i>island. (I
expect they will still be on an IslandsServer if approached
correctly.)<br><br>
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.<br><br>
<br>
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.<br><br>
Keep up the good work!<br>
--Trygve<br><br>
<br>
At 18:07 23.09.2005, you wrote:<br>
<blockquote type=cite class=cite cite="">Am 23.09.2005 um 14:53 schrieb
Trygve Reenskaug:<br><br>
<blockquote type=cite class=cite cite="">My reverse engineering of
Islands may be of interest to others. I <br>
found the objects, their links, and their interaction pattern for a
<br>
few interesting operations. The report is at<br>
<a href="http://heim.ifi.uio.no/~trygver/2005/babyuml/tweakComponents.pdf" eudora="autourl">
http://heim.ifi.uio.no/~trygver/2005/babyuml/tweakComponents.pdf</a>
</blockquote><br>
Note, however, that this is not a conclusive analysis of Tweak
<br>
Islands. In particular, this statement is false (as I explained in
a <br>
private message before):<br><br>
"The objects themselves are floating freely and
their island <br>
property depends on the island of the<br>
observer. The two last print it statements in figure 3 on page2
show <br>
that the same object appear to reside<br>
on two different islands simultaneously."<br><br>
This is wrong. Objects live on one and only one island (unless
there <br>
are bugs etc.).<br><br>
By using the #instVarAt: method you are actively circumventing the
<br>
Island encapsulation. This method was implemented in FarRef in
<br>
particular to aid debugging.<br><br>
In your test, innerObject is a FarRef to an IslandServerInner:<br><br>
innerObject "Far serverIsland:[an
IslandServerInner]"<br>
innerObject island "Far serverIsland:[an
Island(serverIsland)]"<br>
innerObject asString 'an
IslandServerInner'<br><br>
By calling<br><br>
innerObject instVarAt: 2 "an
IslandServerInner"<br>
(innerObject instVarAt: 2) island "an
Island(Squeak)"<br><br>
you directly extract the value of the FarRef and thereby
"tunnel" the <br>
far object onto the current Island. When asking it for its #island
<br>
later, it of course answers the calling island.<br><br>
Without the debugging aids it would be impossible to directly
access <br>
objects on another island. Which would make debugging itself next
to <br>
impossible.<br><br>
- Bert -<br><br>
</blockquote><br>
<x-sigsep><p></x-sigsep>
-- <br><br>
Trygve Reenskaug mailto:
trygver@ifi.uio.no<br>
Morgedalsvn. 5A
<a href="http://heim.ifi.uio.no/~trygver" eudora="autourl">
http://heim.ifi.uio.no/~trygver<br>
</a>N-0378
Oslo Tel:
(+47) 22 49 57 27<br>
Norway<br>
</body>
<br>
</html>