[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:
> 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
Now, when someone have time, can hack there :)
> 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
> "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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev