Sebastian, you can envision that any unique object in VM is a unique
process. No changes required to VM. Your concept having zero worth for
me, because VM already supports that each objects have own
encapsulated state, and you can change object's state only by  sending
messages to it.
So, we already might say, that all objects are living and can be
represented as a processes which triggered by sending message(s) to
them.

On 24/10/2007, Sebastian Sastre <ssastre at seaswork.com> wrote:
> > > > we do copy-on-write cloning.
> > >
> > > But I don't understand why you want to do that if you can just make
> > > that the process of the receiver update it's own memory
> > when receives
> > > that message that 1 was already assigned and 2 no copy is
> > needed at all.
> > >
> > Because a receiver is an object which passed as parameter to method.
> > We can't modify it, thats why - we can't suppose where it
> > passed from and can't suppose it it used in another parallel
> > process, so best we can do is cloning. And since the above,
> > you forced to do same for _any_ method, so you'll go cloning
> > and cloning even by sending self
> > setVar: ..
> >
> Well I see your point. But let me clarify that I talk about something that
> does not suffer of that problem at all.
>
> If we can forget that problem for a minute I can try to show you what I see.
> So here I go:
>
> I don't know if you saw the reference I cited about the Alan Kay's OOPSLA 97
> presentation. Is about an hour and a half or less in duration. It's
> reacheable with youtube.
>
> There at some point Alan talks about someone said once that every host must
> be able to have a valid IP in internet and he states that every object
> should be able to have a valid IP. At first that statement is shocking
> because is too radical. And we don't have resources for that yet. The
> problem is that no matter how radical it is, it's still being a great idea.
>
> As I saw it as just scaling the message passing between objects paradigm
> from image level to interenet level (which is of course massive).
>
> We have no technology to make use of something like that, and maybe is not
> important to try to make that today nor in next five years. But that unhappy
> fact, forced by todays lack of resources reality, does not make that idea to
> be less good.
>
> So we can decide to have the attitude to prepare ourselves to the moment in
> which hardware and industry makes that reality more closer. Could be in next
> 10? 20? 30 years? Nobody knows but we all do know that this industry is very
> accellerated and we are inventing future.
>
> Now I'm trying to think <metaphore>with same software Alan used to sate that
> prhase</metaphore> but in another domain. The domain of processes. And with
> something that todays is closer to us: multicore technology.
>
> So I'm stating here that in a smalltalk image of the future *every object
> should have a process*. Every instance. All of them.
>
> We also could decide to interpret the phenomenon of seing the Erlang VM
> managing 100k processes messaging themselves sucessfully like a mere proof
> of concept to encourage us about hardware starting to turn *less worst*
> creatures than in the past. That way we can start to think that hardware
> it's becoming less worst to the point in wich we can take more seriusly
> making this hardware to manage a quantity of processes of the same order of
> magnitude of the quantity of instances in a smalltalk image. This makes
> feasible to map 1:1 process with instances.
>
> Said that I return to the problem you stated about the need of copy copy
> copy, saying that this premise changes things and you don't need to copy
> anymore because a VM like that, no matter who or when, an instVar of an
> object is to be modified it will provide you of guarantee that the write
> will be made by the process that corresponds to that instance.
>
> This idea is redefining what we understood today as anObject by *coupling*
> it to aProcess. In this hypothetical smalltalk anObject can't live without a
> process. It's indissociable.
>
> So.. in this hypothetical smalltalk:
>
>         - we can supose that every object lives in a process
>         - we can supose that nobody but the very owner of an instVar can
> write that instVar
>         - we can supose that no other process but the one of that instance
> will write that piece of RAM
>         - we can supose that everythig is an object
>         - we can supose that all the instances-processes can be freely
> balanced trhough cores
>
> Besides:
>         - we have no need to pollute syntax nor smalltalk rules
>         - we are not introducing singularities in the paradigm
>         - we do are consuming more resources but in compensation of gaining
> unprecedent scalability
>         - we are keeping the heuristic, completism and simplicity that
> defines smalltalk
>         - we are making a step forward in anthropomorphism that will
> maintain smalltalk concepts familiar to persons - last but not least: we
> take advantage of multicore cpus transparently
>
> Take a minute to think in it's consequences. This suposition, same concept
> in more explicit words, this assumption of anObject being an indissociable
> thing with aProcess, objects being 1:1 with processes, makes all the
> difference and dramatically simplifies all. An we do know that
> simplification improves scalability.
>
> I'm, of course, being extremely speculative in the exploration of this idea
> in group with you all. But think is cheap :). In fact I don't even buy it
> myself yet. The problem is that I'm honestrly unable to refute myself about
> the convenience of this path :) so it becomes stronger.
>
> I hope you and others understand why I'm starting to think that this is a
> powerful idea.
>
>         all the best,
>
> Sebastian Sastre
> PS: Sorry for the size. I've tried to express this in my previous post. I'm
> trying to be didactic and illustrative.
>
> >
> > > Cheers,
> > >
> > > Sebastian
> > >
> ...
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.