> >  Yes, and how would the no sharing be implemented in Smalltalk?
> 
> This is what my investigations will reveal.  As I alluded to 
> in a previous mail, any immutable data is not a concurrency 
> issue.  It doesn't matter who can see it so long as it can't 
> be updated.  Mutable data (e.g. objects) are also no issue 
> provided you can guarantee no process can get access to it 
> besides the process that created it.
> 
> So that leaves globals, especially classes.  Until I get into 
> this I'm now 100% how I'll deal with it, but I can't image 
> that it's not solvable.
> 

Jason, I'll describe what I understood about your idea of solution so please
correct me if I don't get you right. 

<description>
The idea you are exploring is about a Smalltalk in which one can send
messages to processes, this is, object processes which are instances of
something that can't be defined as the processes we know today not in the OS
not in the current smalltalk vm's but more like the Erlang ones (extremely
cheap). Note: for practical use I will desambiguate this new concept calling
them as if they where instances of ObjectInProcess.

So lets imagine now this smalltalk which instead of the Object class we know
it has today it has an ObjectProcess base class and all it's subclasses are
kind of hierarchy we have today.

In this smalltalk, the VM guarantees that any instance can look anything
about any creature of this virtual universe but nobody can modify it. So
exists an strict respect of encapsulation. The modification of instVars can
only happen if made by the objectProcess instance X itself and VM makes
imposible to me modified differently from this.

So anObjectProcess will listen to messages but for the rest of the creatures
of this image it has read only instVars. If other anyObjectProcess want to
say something to it that demands a modification of some instVar that
modification is again guaranteed by the VM that will be made only by itself.
So creatures in this virtual universe can make pressure or ask kindly to any
other objectProcess creature that it make a change but the reality is that
universe guarantees strinctly that the change can be made only by itself.
</description>

<analogicCuriousObservation> 
This is starting to sound strangely familiar to me: anybody can try to
convince me about how things are, etc. but as owner of my "hardware" I'm the
only creature that can change my synapses.
</analogicCuriousObservation>

So in a previous example of yours any instance of any object (that reaches
it) can make:

(Processes at: 'bank account') addUSD: 5000

and the correct instance in it's own process modifies the instVar.

OK.. here go what I think:  

What I think is that messages should not be made special between processes.
That smells badly. They should be normal and homogeneous. What should be
refactored is the Object concept refining it's definition (in this new
smalltalk version) to an object that lives in a process. We don't need to
change the word but refine the definition, and conceptual interpretation of
course, of what a smalltalk object is!.

We allways talk about smalltalk being a space of live objects and that it
has a kind of anthropomorphic philosophy. Sorry this is strong but maybe
this hardware shift are telling us that time has come to ask us about the
need of the LiveObject class instead of Object to keep having the most
complete and minimalist paradigm of the industry. I'm not saying the name
formally is just to illustrate the value of time affecting instances. Of
course is not alive, it's also to illustrate emphatically about the
evolutionary timeline of any instance. The things it will experiment once it
start to exist in the image. The evolution in time is what we call "Process"
(not today in this industry but maybe soon).

IMHO the Object class, in the way we know it today, does not contemplate
what Alan claimed in OOPSLA 97 about taking in mind the process part as
being of such importance. The very own existance of an instance depends
(inherently) in the experience it will suffer in time. And today we have no
holder for that. 

Besides the very nature of objects (now I mean in real life) is that they
are not frozen in time. Even a piece of ice has strong molecular activity
that we can interpret as being __molecules in processes__ inside.

Refining that concept to allow Object to become more like this LiveObject,
ProcessObject or ObjectInProcess (whatever I don't care about names now, but
I prefer to maintain calling it Object) will mean that we care about
creating the possibility of seriusly modeling this reality about experience
in time that objects suffer.

If we use smalltalk because it's nature is to be heuristic, this is familiar
respect to reality, then maybe it's time to explore stop keeping the process
concept with such a low priority from the design point of view and equalize
the importance, again at design level, of the experience of the objects in
time.

What we have today is that the st vm's makes objects to be supported by
other objects running in vm threads but this idea it's about making objects
to be existing __in__ a process. A process of it's own. All of them.

So in this imaginary smalltalk a process and an object are indissociable
they don't exists as separated entities. 

In an hypothetical simulation of the dynamic of one of this brain tides,
every object MessageOfNeuron (may be hundreds of millions) run chemically on
a process that goes ahead by it's own through someAxon and someDendrites of
someNeurons.

So this simulation will run more efficiently in this smalltalk and modeled
as an object and modeled more closer to reality and every MessageOfNeuron
instance will run balanced in N cores.

Wow! I'll stop here by now but this is as much radical as interesting.

I'll appreciate criticism of all about this. Any kind of it, I don't care,
this idea seems to me too important.

Now a technical question:

As said before a squeak image easily has 800k instances. Erlang was claimed
to have about 100k processes without problem (I don't know in which
hardware). Of course that a proof of concept should start small but I'm
worried about that we still need to run about 800k vm _instance processes_
to achieve the goal. I wonder how that will not be a problem?

Jason, please keep us informed about any progress,

	All the best,

Sebastian