Martin,

I totally agree with you that when it comes down to *really* refactoring
the class SystemDictionary, the whole thing needs some more thoughts. In
this sense, I of course didn't mean that we should take my examples as a
concrete suggestion for how to refactor this class!

Much more, I just wanted to show that there *are* ways to
cleanup/restructure overloaded function holder classes without making
Smalltalk less usable/understandable/extendable.

So, the thing that remains to do is to actually go over this class and
*carefully* try to find a reasonable way of splitting it up.

Nathanael



> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Martin Wirblat
> Sent: Montag, 16. Juni 2003 15:52
> To: Squeak
> Subject: RE: [KCP] SystemDictionary cleaning: Comments and design
> 
> 
> >- "System fullNameForChanges:" is simpler than "Changes fullName:"
> >- "System fullNameForImage:" is simpler than "Image fullName:"
> >- "System listBuiltinModules" is simplar than: "BuiltinModules list"
> >- "System listLoadedModules" is simplar than: "LoadedModules list"
> 
> Nathanael, 
> agreed on the first two but not so much agreed on the other two: 
> "System builtinModuleNames" and "System loadedModuleNames" should it 
> be from a POW of Smalltalks naming convention. #list could popup a 
> window as could do #listBuiltinModules. "System" is not 
> redundant! You may not know when reading "BuiltinModules 
> list" in some code what 
> BuiltinModules are. You may think it is a class var and 
> belongs to the 
> specific code in question. 
> 
> Furthermore most utility-selectors will not allow you to 'extract' a 
> className. Conversely some selectors in Squeak include the className 
> for linguistic reasons. 
> 
> >addModulesToMenu: modules
> >	...
> >	modules list do: [:each |
> >
> >And you can invoke this method for both BuiltinModules and 
> >LoadedModules. This would not be possible with the first 
> approach. So, 
> >why do you not want to take advantage of OO programming here? Why do 
> >you like procedural programming better?
> 
> Most actions of these utilities are special, there is a good chance 
> that you can't extract a common selector. In most cases you will not 
> be able to define similar classes too. Thus you can't take advantage 
> of OO programming. 
> 
> So you searched and found specific cases! 
> Here is my specific counter-case:-) 
> 
> System memoryHogs -> Memory hogs
> 
> In some way you showed with your examples that there _is_ a danger to 
> create too many new classes, once one started with the first one. I 
> guess that is why I suggested to better stay with one, than have too 
> many. For your examples I would say: 'Image' perhaps, but 
> 'BuildinModules' probably not. 
> 
> What are the rules for making a new class? Hard to say, and exactly 
> this is another reason why there is little help for being stopped to 
> do so. 
> 
> My feeling about such a rule is this:
> These 'function-holder' classes are missing the primary 
> reason to make 
> a new class, that is, that there will be some instances of it. They 
> even have no subclasses. If such objects don't have own individual 
> data ( in inst vars ) they should at least represent a formidable 
> object of the system which everyone has in mind and they should not 
> have to few methods. 'System' the machine which brings Smalltalk to 
> you, would be such a formidable object. 'Image' perhaps ( newbies 
> often don't know that there is an image, but they know that 
> there is a 
> system ) but 'BuildinModules' is not enough. 
> 
> regards,
> Martin
> 
>