Questions about ToolSet

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions about ToolSet

Mariano Martinez Peck
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Questions about ToolSet

Schwab,Wilhelm K
As long as you make it no harder for me to use the old inspector, I'm open to just about anything.  No arguement that toolsets in their current form are strange.



From: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
Sent: Tuesday, February 02, 2010 6:00 PM
To: Pharo Development
Subject: [Pharo-project] Questions about ToolSet

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Questions about ToolSet

George Herolyants-3
In reply to this post by Mariano Martinez Peck
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 <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Questions about ToolSet

Tudor Girba
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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Questions about ToolSet

Mariano Martinez Peck


On Wed, Feb 3, 2010 at 9:29 AM, Tudor Girba <[hidden email]> wrote:
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

and accessors :)
 
. Like this you do not create
unnecessary global state.


Thanks Doru!!! I like much more my suggestion. Actually it was just what I come to mind at that time. The real purpose was to see if other people agree there is a problem in ToolSet.

Thanks! I created the issue http://code.google.com/p/pharo/issues/detail?id=1915

Now, when someone have time, can hack there :)

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Questions about ToolSet

Stéphane Ducasse
In reply to this post by Mariano Martinez Peck

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