Hi, I think that introducing more global state is not a good idea. I believe a cleaner solution would be to create have ToolSet default return an instance of a ToolSetImplementation, and then create a instance variables in the ToolSetImplementation for these tools and let me customize it from outside. Like this you do not create unnecessary global state. Cheers, Doru On 3 Feb 2010, at 09:11, George Herolyants wrote:
Hi, Mariano
I also confronted this problem when I was writing some extension of NewInspector. And I agree, the current process of registering of new tools is ugly. I solved the problem with writing some code, which created an anonymous class which merged behaviour of all the tool sets passed to it as arguments and installed this class as default tool set. Tricky way, but it worked, IIRC :).
But I think there should be cleaner way. Maybe something similar to what you propose, but without introducing new names in the global namespace. Maybe we can do define all those tool classes as class variables and define a protocol in ToolSet or StandardToolSet to install (and maybe even use new settings framework to do it)?
What do you think?
George
2010/2/3 Mariano Martinez Peck <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."