Hi!

> -I browse, and I find a system class, like DisplayScreen. I want to
> modify the current instance of it. The documentation says that its
> instance is always called Display. OK, so now I know. But there is no
> really active way to find out about the instances of a class that I can
> address.
>
It is possible: bring up the method pop-up menu, select "more...".
There you find "inspect instances" and "inspect subinstances".
(yes, these menu-items should be in the class-menu...)

An other interesting thing is to use "someInstance" in the Workspace.
When I do a Squeak demo, I allways show the BouncingAtomMorph. 
Then I open a Workspace-Window, and do:

  AtomMorph someInstance color: Color red.

then:

  AtomMorph someInstance velocity: 0 at 0.

"someInstance" returns the same Object on every call, so our red
Atom now does not move. 

-> bring up a halo
-> drag from the green handle a copy outside.
-> Inspect the AtomMorph (grey handle, inspect)
-> edit the velocity variable (1 at 0), you can change the color if
   you want, too.
-> drag the AtomMorph back into the green Box where the other atoms are.
-> bring up the halo, bring up the menu via the red Button
-> select "embedd..", select "BouncingAtomsMorph". Now the AtomMorph
   starts to move again. 

Ohh... yes: What I really wanted to say: There are some ways to
find the instances of a class. But the problem is (I think), rooted much 
deeper than simply moving these menu-items to the class popup menu...

The problem is that the browser only shows the *static* relations
between classes. Most people that learn OOP thus focus on classes.
They think that "OOP is that thing with classes and inheritance".
But inheritance isn't that important... *relationship* between 
the Objects is the important thing. 
(Java and C++ have the same problem: they only provide language 
constructs for classes and inheritance)

(Alan described this a year ago in a mail to the list:

|  Date: Fri, 9 Oct 1998 21:40:35 -0700                                            
|  To: squeak at cs.uiuc.edu                                                          
|  From: Alan Kay <alank at wdi.disney.com>                                           
|  Subject: Re: prototypes vs classes was: Re: Sun's HotSpot             
|
|Folks --
|  
|Just a gentle reminder that I took some pains at the last OOPSLA to try to
|remind everyone that Smalltalk is not only NOT its syntax or the class
|library, it is not even about classes. I'm sorry that I long ago coined the
|term "objects" for this topic because it gets many people to focus on the
|lesser idea.
|
| ............

is this in some list-archive? egroups starts at 11.98....)

Morphic is a good example for this: The Morph inheritance-hierachy
is not the important structure of Morphic: It's the submorph-hierarchy.
And this is not at all made explicit in the browser... 

> Also here, a note on Morphic: I dare say that Morphic isn't really OO
> anymore. Although my figure on the screen is _one_ object, there is a
> Morph, a Player and maybe even some MVC subclasses (dunno) associated
> with it. Its behaviour can be defined in more than one way, and for
> almost every new usermorph a new class has to be constructed, although
> it could be easily modelled as a new instance. For every Morph there is
> a Player class name, a Morph class name and an internal name, but
> there's only one object for the user.
>
Is your visible object on the screen really *one* object? Every
more complex morph consists of many submorphs... 

There was a discussion about this a year ago: 

Marcel: http://www.egroups.com/group/squeak/282.html?
Alan:   http://www.egroups.com/group/squeak/283.html?

> Morphic could be a good system on it's own. Currently, it almost seems
> to me like it has trouble being implemented in Smalltalk, though. 

That's why it is called "Squeak", not Smalltalk: If we find a better way,
we can enhance the language. 

 Marcus

--
Marcus Denker marcus at ira.uka.de phone at home:(0721)614235 @work:(0721)608-2749
Even a database has a point of view -- Ted Nelson