[Pharo-project] Questions about ToolSet

Mariano Martinez Peck marianopeck at gmail.com
Wed Feb 3 08:17:32 EST 2010


On Wed, Feb 3, 2010 at 9:29 AM, Tudor Girba <tudor.girba at gmail.com> 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 <marianopeck at 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 at lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > 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
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20100203/442fb4b7/attachment.html>


More information about the Pharo-dev mailing list