2008/10/28 Pavel Krivanek <[EMAIL PROTECTED]>: > Hi, > > we should decide how we will manipulate with tools. A lot of tools > classes are referenced directly - that is wrong because you cannot > then use different set of tools (for example a dummy toolset for no > tools at all). > In the KernelImage I added a registration mechanism for tools so they > were called for example ToolSet default browser. There were no ToolSet > subclasses and there was only a test if the default ToolSet is not > nil. That was not optimal solution. > > The current philosophy of ToolSet class supposess that you will send > messages directly to ToolSet class and you will not get real tools > classes at all. However the set of this messages would be very long > and Squeak wants sometimes directly the class (for comparison etc.) >
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like: Smalltalk tools browser here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key. Also, if you want to add new, or replace old tool you just write: Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc... as well as remove: Smalltalk tools remove: #workspace With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
