On Feb 3, 2010, at 12:00 AM, Mariano Martinez Peck wrote:
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 ?
Apparently what you want is a kind of factory ToolSet is a facade StandardToolSet is an adaptor making the glue between the protocol of ToolSet and the actual tools. So delegation is not that bad. now by adding a inheritance relationship we could reuse default code when possible. inspectorClassOf: anObject "Answer the inspector class for the given object. The tool set must know which inspector type to use for which object - the object cannot possibly know what kind of inspectors the toolset provides." self default ifNil:[^nil]. ^self default inspectorClassOf: anObject the self default ifNil: [^nil] looks also suspicious.
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)
I like the suggestion of doru. ToolSet should have a way to registering new tools to specific protocol and that you can access and change a given set. One of the problem is that it can be easy if all the tools kind (all debuggers) agree to follow the same interface to get opened.... Stef