Hi andreas


> Hm ... sounds almost like "I'm amazed to see how difficult it is to do 
> a
> stupid small program in Squeak which requires object orientation (ok, I
> don't use objects)" ;-)))
>
> For your example, you should actually come up with a model of what it 
> is
> your bots are doing.

This is what I'm trying to do now because I always fall in the trap that
I end up with concurrent objects executed in various implicit thread. I 
got the same problem with the animation for the turtle. The problem is 
that I want plain normal code to be able to be executed and not just a 
subset of well identified methods.
Nathanael wrote several version of the AnimatedTurtle just because we 
had problem with the user interaction event and condition breaking the 
animation.

> As you are talking about animation, you are also
> talking about time. In other words - if you don't tell your bot how 
> fast it
> can do its work, then you're just assuming that it's infinitely fast 
> and, of
> course, you will not see any progress during the simulation. The best 
> way to
> handle this is by assocating time with the object directly so it can 
> evolve
> over time

Do you mean something similar to stepTime telling to a scheduler the 
frequency to be executed?

> (not surprisingly, this is exactly what TeaTime in Croquet is
> about) and effectively have the system visualize its state "as often 
> as it
> can" rather than explicitly.
>
> Given that this is not exactly trivial (but noone said that graphics is
> trivial, eh?!) you may want to have a more discrete model of what your 
> bots
> are doing (for example: "a bot can #go once per frame"). Given only a 
> single
> bot, then #displayWorld or similar in the right places will work 
> perfectly
> fine (and are utterly trivial). If you don't - e.g., you want users to 
> be
> able to interact with your objects, or have many of them - then you 
> simply
> have to be concurrent or how else would your objects _actively_ 
> control what
> is going on? So that, by the end of the day, your problem can only be 
> solved
> in a "good object-oriented way" if you realize that it is an 
> intrinsically
> concurrent task.



I know. I got exactly the same problem with my turtle morph (multiple 
turtle running in parallel with user interaction and world update)but 
the solution was rather complex. I would like to avoid to fall into 
that complex solution again
So what would be solution? in the turtle I do not remember the number 
of approaches I tried like having one thread per object, object 
yielding .....


>
> Cheers,
>   - Andreas
>
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html