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