[Squeakfoundation]Just let me know if I lose my time and yours

[Stephane Ducasse]

Hi guides and others

I can tell you that the last email of Andreas makes me think a lot.

I'm a respectable researcher, I have a lot of cool ideas and write a 
lot of smart
papers, I have lot of fun programming in Smalltalk, organizing ESUG, I 
have kids,
and a nice social life.

But I do not need KCP, really I do not need it. I do it because I feel 
it important.
Now if you think that I'm over cleaning, over refactoring, if you think 
that I'm
creating too much classes and that Squeak should stay the way it is, 
please let
me now immediately because I ***really*** have something else to do for 
my evenings.
I have enough to do. Really!

You may think that I'm over exaggerating, in such a case consider that 
this over
exaggeration is the clear sign that I have something else to do.

Stef





From: Stephane Ducasse <ducasse at iam.unibe.ch>
Date: Wed Jun 11, 2003  10:14:15 PM Europe/Zurich
To: The general-purpose Squeak developers list 
<squeak-dev at lists.squeakfoundation.org>
Cc: Roel Wuyts <wuyts at iam.unibe.ch>, Alexandre Bergel 
<bergel at iam.unibe.ch>
Subject: Re: [KCP] SystemDictionary cleaning: Comments and design

Come one andreas

	Image abandoneSources

Does not tell you something?

Please tell me that I'm wrong and stupid to lose my time cleaning 
Squeak and I stop.
Seriously. No joke. I have something else that hearing that.


Stef

On Wednesday, June 11, 2003, at 09:18 PM, Andreas Raab wrote:

> Stef,
>
>>>  Look for instance at Utilities class comment. It
>>> says: 'methods that don't naturally attach to anything else'. These
>>> methods are functions and you won't create instances of the new
>>> classes, they are just more or less function-holders. There is no
>>> complicated interdependency of classes and methods to understand. It
>>> is only a question of 'listing' these functions.
>>
>> If this is what **you** believe...
>
> And me too. If there is a recognizable concept for a number of methods 
> which
> make sense to think about them as "attached to" a common class (system
> navigation for example) then I'm all for it. But in many other cases we
> merely have utility functions and forcing "arbitrary concepts" will 
> only
> make things more complex - mostly you will start moving around the 
> methods
> for the mere purpose of putting them NOT into a specific place which 
> means
> you'll have much more confusion in the long term.
>
> For example, consider a method like #abandonSources. I don't see any 
> easy
> place where this method should live and if you would forcefully "clean 
> up"
> SystemDictionary then all you know is that you do NOT want it there - 
> but
> you've got no good concept yet where to stick it otherwise. Let's 
> consider
> someone says "let's put this into FileDirectory" because it does 
> something
> with files. Now, any code has to be rewritten against file directory. 
> Except
> that at some later point someone might say "oh, it really belongs into
> FileStream" and then any code has to be rewritten against that place. 
> And so
> on. In the long-term, there are always going to be some utility methods
> which cannot be cleanly attached to some class or other and then it's 
> really
> more about "listing" them.
>
> The bottom line of this is really: a) Think *very* carefully about the
> classes (concepts) you want to introduce for utility methods. b) 
> Provide a
> (couple of) generic places where utility methods can live. Right now 
> we have
> two such places - SystemDictionary which holds most of the "environment
> related" utility methods and Utilities which holds most of the rest.
> Introducing a hundred new classes all of which have one or two methods 
> just
> so that they are NOT in some place isn't very good design either. IMO 
> at
> least.
>
> Cheers,
>   - Andreas