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