[Pharo-project] ToolSet

Igor Stasenko siguctua at gmail.com
Tue Oct 28 15:26:34 EDT 2008


2008/10/28 Pavel Krivanek <pavel.krivanek at 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.




More information about the Pharo-dev mailing list