Hi Roel,

> It is not as simple just saying that The Right Thing is this or
> that, since it heavily depends on what you want to do. What 
> responsibilities you give to an object is what makes OOP hard
> (not especially the programming). And these responsibilities
> change over time as the system evolves. Squeak is evolving
> right now, so what once was a clear and good decision to
> let Classes know about the structure of their instances,
> about how to create instances and about all the
> meta-programming structure does not necessarily hold anymore.

I certainly agree, but so far no convincing argument to the contrary has
been made, except from either stating that it is "bad" (with five or more
exclamation marks attached ;-) or that it is Not The Right Thing To Do.

> For example, if you want to build a browser that works on code not
> inside your image, then having these 'right' methods there will kill
> you.

And why would that be? Perhaps you haven't read my message carefully but I
have very clearly stated that for something like a browser it seems quite
appropriate to have a navigator at hand. But given that I know I am talking
to classes in my image if I want to inquire one of the classes about certain
properties, why would it kill me if these methods were there?

In addition, in order to be even able to talk to some code that is not
inside your image you still need to have a "handle" to refer to. If you call
that handle an "object" then this object may implement the appropriate
queries. And, lo and behold! The mere existence of the methods will not kill
you. Isn't it amazing what you can do if you think object-oriented? ;-)))

I think that the major trouble we're having in this discussion is caused by
an assumption that every last place in the system absolutely has to use the
most general mechanism available. That is wrong as in 99% of all of the
common cases a simple solution is just what you need. If you can provide for
generalizations by, for example, providing a navigator in the browser and
encourage people to use that navigator when they hack their own browsers
that's fine. But don't forget about the many situations in which we just
want a quick answer to some question! You're making it incredibly hard to
use the system in the most convenient way, which, by the end of the day,
means we're loosing a significant amount of productivity.

> On to the pink plane! Let's make Squeak a better system.

Better for whom? For researchers to study, for newbies to learn, for
programmers to use? For two out of the three I would claim that the "better"
system is the one where these things can be gotten to easily and
conveniently.

> PS: The reason is the 'stratification' I talked about in the other 
> mail: you are assigning responsibilities to Class which are not 
> necessarily the right thing. A detailed example is in an upcoming 
> Bracha&Ungar paper that talks about techniques to have a clean MOP in 
> OO languages (so basically about Mirrors and its different 
> incarnations in Self, Strongtalk and the Java Debugging Interface).
> The distributed browser example is what they use to illustrate 
> 'stratification', one of the concepts they introduce.

Please send me a copy of this paper as soon as it is available.
'Stratification' (for which the definition is rather unclear to me; it would
be helpful if you could give us an understanding of what is actually meant
by the term) may be a useful thing for system structuring but by the end of
the day it's efficiency and intuition that counts. And as much as I like
well-factored systems, if they are divided in ways which only make it hard
for users to actually get the results they want, then that factoring is
simply useless. Mind you, we are not talking about a pure research prototype
here - some people actually want to use that system.

Cheers,
  - Andreas