On Friday, Aug 15, 2003, at 08:48 Europe/Zurich, Daniel Vainsencher 
wrote:

> Roel, can you explain the stratification stuff in more detail?
> specifically, justify and qualify the statement "meta-level facilities
> must be separated from base-level functionality.".

See a mail five minues before this one in the same thread. I hope that 
makes it clear. But take care: like I try to explain in that mail (but 
it is a big one, so I am afraid it is not really clear): I do not want 
Squeak to be a fully stratified systems that uses Mirrors! That would 
be a Research Goal, not a KCP thing. But the ideas are the same. 
Chopping up things that are currently belonging together to enable new 
flexibility. I agree with you and some other people that we will add 
some form of 'sugar methods' to make it shorter to use again. Whether 
this will be a global variable or class methods or ... I do not know 
yet (Stef will do this as soon as he has some time again). For a fully 
stratified system that would be a big 'nono', but that is why this is 
KCP and not research. We're aware of this issue :-)

>
> Also, there is a package modeling mechanism that is currently being
> included in the official image, and whose information won't be lost 
> even
> when it is superceded - PackageInfo. Is there any reason not to make at
> least the most useful of the messages discussed class extensions on
> Class? (I don't know what you mean by "official, good, supported
> mechanism". If you want I can hold your hand as you reclassify the
> methods and then send you an outrageous bill ;-)

Since the KCP things go into the base system, this would mean that 
PackageInfo should also be part of the base system. Otherwise you have 
circular dependencies. I thought this was not the case (don't shoot me 
if it is :-) I haven't had time to check :-( ).

>
> Joshua: I don't see why you differentiate between production code and
> the workspace. IMO, simplicity and conciseness are far more important 
> in
> production than in workspace code - that's why we have a refactoring
> browser, not a refactoring workspace...
>
> Daniel
>
> Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
>> This is mostly a me too.  As long as we are careful to separate the
>> "convenience" methods/globals from the "production" methods, there's
>> no harm in the convenience methods existing.  If you insist on leaving
>> out the convenience methods, then you have just made the system more
>> inconvenient to interact with.  In production code, you can write
>>
>> 'SystemNavigation default allCallsOn: aSelector from: aClass'
>>
>> but if I'm typing in a workspace, why shouldn't I be able to type:
>>
>> 'Navigation allCallsOn: aSelector from: aClass' or even
>> 'aClass allCallsOn: aSelector'
>>
>> Disallowing these discourages exploratory workspace programming, and
>> moves Squeak towards being Java (VisualAge Java has a Workspace, but
>> it is hell to use because you have to type way too much).  There are
>> definitely reasons to use the long expression in production code,
>> since it provides a flexible layer of indirection that's very helpful
>> for all the nifty stuff going on in Berne.  But like Andreas said,
>> having the convenience methods there can't kill you if they're not
>> called.
>>
>> Granted, it takes discipline to make sure that calls to the convenient
>> methods don't creep in to the image.  Perhaps it was in this sense 
>> that
>> you meant that the convenience methods "will kill you".  However, we 
>> have
>> a much better code review process in place now, so I don't think that
>> this would turn out to be a serious issue.
>>
>> If it turns out to be a bigger problem than I think, then we've just
>> found a Research Opportunity.  Perhaps some sort of composition model
>> could be used so that the convenience methods could be used in DoIts
>> and quick Morphic hacks, but would not be visible when writing
>> production code.  I don't know exactly how this would work, but hey,
>> you're the SCG and I'm working on graphics; you figure it out ;-)
>>
>> Joshua
>>
>>
>>
>> On Fri, Aug 15, 2003 at 02:34:09AM +0200, 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
>>>
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org