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