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 <[email protected]>: >> 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 >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > 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." _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
