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