Hi andreas

just to make a point clear. All the work we do in the context of KCP is 
not related to research.
Our concerns is to provide better system for people using t and 
developing real applications.

Stef


On Friday, August 15, 2003, at 02:34 AM, Andreas Raab wrote:

> 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
>
>
>