I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too. Stef On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote:
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
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