Hi folks. I found I big problem with the way ToolSet works or at least with
the way I think it works.  Right now, there is the class ToolSet with
certain methods like API and then a class side method to register a XXX
ToolSet as default.  So, we have for example, the StandardToolSet which
implements/overrides some of the methods of ToolSet. Of course, that ToolSet
(StandardToolSet) is the default. Evaluate ToolSet default and you will get
that one. Becuase that is done is StandardToolSet class >> initialize

Now...the first question,  why  StandardToolSet doesn't extend from ToolSet
? shouldn't that be better ?

Anyway, this is the big problem. The only way right now to change the
toolset is to create a new class and register it. Suppose I want to install
NewInspector and put in the ToolSet that now, the inspector to use is
NewInspector instead of old Inspector. The only way I see right now is to
create  new class and implement the method inspectorClassOf:  As you can
see, NewInspector had to do that in class NewInspectorToolSet. They had to
create that class just to implement that method and register it...

Now, suppose I want to install shout, and I want to say that the default
workspace is SHWorkspace (shout one), not the normal one. Ok...easy, I do
the same of the NewInspector (but changing the method openWorkspace instead
of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I have or
NewInspectorToolSet or ShoutToolSet. Of course, this has no sense AT ALL.

So, my proposal is to change ToolSet, so that any tool can change certain
things, without needing to do that. Examples:

For example, in StandardToolSet, we have:

StandardToolSet >> openWorkspace
    Workspace open

I would change that for something like:


StandardToolSet >> openWorkspace
    (Smalltalk at: #WorkspaceClassName) open

Of course Smalltalk at: #WorkspaceClassName  must be initialized the first
time with something like Smalltalk at: #WorkspaceClassName put: Workspace

I don't like the name WorkspaceClassName, we should look for better names.

Then, I can just have a post do it when loading Shout that evaluates:

(Smalltalk at: #WorkspaceClassName put: SHWorkspace)

Here there is no need to create subclasses neither to register a new
toolset.

Ok...this is an example, but the idea is to apply this to most cases.

What do you think ?

Mariano
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to