[Pharo-project] ToolSet
Hi, we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution. The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.) The default tools are: browser changeList changeSorter changedMessageSet classCommentVersionsBrowser classListBrowser debugger dualChangeSorter hierarchyBrowser instanceBrowser lexicon messageNames messageSet packagePaneBrowser pointerFinder protocolBrowser versionsBrowser Cheers, -- Pavel
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like: Smalltalk tools browser here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key. Also, if you want to add new, or replace old tool you just write: Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc... as well as remove: Smalltalk tools remove: #workspace With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant. -- Best regards, Igor Stasenko AKA sig.
I'm wondering what problem is exactly trying to be solved? From the start of the thread it strikes me as over engineered. If tools have to appear in the model layer, i.e. they are programmatically used then making them pluggable requires that all different examples of the same 'tool' respond to the same protocol. If that was the case I would prefer that Pharo put efforts into the best tool for each category. i'm not sure we need two debuggers or two pointer finders for example. In specific cases if you want to resolve UI/headless issues then perhaps there is a better way. For general registration into menus, I consider this UI layer where the only reference to the tool would likely be loader code to populate the menu. In that case we already have a registration mechanism I thought (?) and I don't see the problem with a direct class reference. just my 2p thanks Mike
2008/10/28 Michael Roberts <mike@mjr104.co.uk>:
I'm wondering what problem is exactly trying to be solved? From the start of the thread it strikes me as over engineered. If tools have to appear in the model layer, i.e. they are programmatically used then making them pluggable requires that all different examples of the same 'tool' respond to the same protocol. If that was the case I would prefer that Pharo put efforts into the best tool for each category. i'm not sure we need two debuggers or two pointer finders for example. In specific cases if you want to resolve UI/headless issues then perhaps there is a better way.
Sometimes you want to stub out a tools to make them inaccessible. Or replace them with different ones. For instance, one would like to redirect Transcript output to file, or suppress debugger / browser / inspector. This can be useful for different applications, which is targeteg for users, not developers.
For general registration into menus, I consider this UI layer where the only reference to the tool would likely be loader code to populate the menu. In that case we already have a registration mechanism I thought (?) and I don't see the problem with a direct class reference.
just my 2p
thanks
Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
It is not always good practice to do "deep" examination... each level can be a facade... (e.g. "Smalltalk tools browser" might be better as "SmalltalkTools browser")... Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Tuesday, October 28, 2008 7:26 PM Subject: Re: [Pharo-project] ToolSet
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like:
Smalltalk tools browser
here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key.
Also, if you want to add new, or replace old tool you just write:
Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc...
as well as remove: Smalltalk tools remove: #workspace
With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too. Stef On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote:
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like:
Smalltalk tools browser
here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key.
Also, if you want to add new, or replace old tool you just write:
Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc...
as well as remove: Smalltalk tools remove: #workspace
With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Igor Stasenko wrote:
Sometimes you want to stub out a tools to make them inaccessible. Or replace them with different ones. For instance, one would like to redirect Transcript output to file, or suppress debugger / browser / inspector.
The proposed solution is more a symptom fix than a real solution. You want to make the number of access points as small as possible, so you have e.g. one point where to turn off the debugger. By that I mean turning off the debugger and not trick the system by stubbing it out. Same for access to Transcript. There shouldn't really be *any* direct reference to Transcript to begin with, but rather a small but effective logging API, e.g. Josef's toothpick. We Smalltalkers (I just happen to reply to Igor here, I'm including myself in this remark too ;-) ) tend to use magic tricks just because we can, but that doesn't mean it is good engineering. Michael
IMO discovery is a preferable model to registration, using either pragmas or pragma-like constructs. In Commando I do this: createCommands LSDCommando thisMethodReturnsAListOfCommands. .... and commandStructureTransformers LSDCommando thisMethodReturnsAListOfCommandTransformers. ... where the thisMethod... methods are empty. To collect all the methods that generate commands I do a senders-of-XXX-in-descendents-of-Class- that-have-an-LSDYYY-reference search. You could do more sophisticated filter after the search by bytecode analysis. One benefit of discovery is that (IMO) reuse is conceptually easier because (in the case you are talking about in this thread) the concept of 'being-a-command' is separated from 'in-the-world-menu'. Squeak has pragmas now, which people might prefer to traditional reflection. Personally I don't. On 29/10/2008, at 8:49 AM, Stéphane Ducasse wrote:
I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too.
Stef
On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote:
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like:
Smalltalk tools browser
here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key.
Also, if you want to add new, or replace old tool you just write:
Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc...
as well as remove: Smalltalk tools remove: #workspace
With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis
Yes I was thinking about that too for building a Preference class that would not be called by the tools during their execution but that would query the pragma to get contents. Now the registration has the advantage that you load the tools and it is registered. Stef On Oct 28, 2008, at 11:42 PM, Antony Blakey wrote:
IMO discovery is a preferable model to registration, using either pragmas or pragma-like constructs. In Commando I do this:
createCommands LSDCommando thisMethodReturnsAListOfCommands. ....
and
commandStructureTransformers LSDCommando thisMethodReturnsAListOfCommandTransformers. ...
where the thisMethod... methods are empty. To collect all the methods that generate commands I do a senders-of-XXX-in-descendents- of-Class-that-have-an-LSDYYY-reference search. You could do more sophisticated filter after the search by bytecode analysis.
One benefit of discovery is that (IMO) reuse is conceptually easier because (in the case you are talking about in this thread) the concept of 'being-a-command' is separated from 'in-the-world-menu'.
Squeak has pragmas now, which people might prefer to traditional reflection. Personally I don't.
On 29/10/2008, at 8:49 AM, Stéphane Ducasse wrote:
I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too.
Stef
On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote:
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like:
Smalltalk tools browser
here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key.
Also, if you want to add new, or replace old tool you just write:
Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc...
as well as remove: Smalltalk tools remove: #workspace
With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Some defeats are instalments to victory. -- Jacob Riis
I'm still looking for people to help cleaning the PopUpMenu plague. the idea would be to change PopUpMenu -> ToolBuilder but this is not the solution. the PopUpMenu should be converted into a Warning and lot of PopUpMenu should be removed. Now what is the answer to pavel question? On Oct 28, 2008, at 11:23 PM, Michael Rueger wrote:
Igor Stasenko wrote:
Sometimes you want to stub out a tools to make them inaccessible. Or replace them with different ones. For instance, one would like to redirect Transcript output to file, or suppress debugger / browser / inspector.
The proposed solution is more a symptom fix than a real solution.
You want to make the number of access points as small as possible, so you have e.g. one point where to turn off the debugger. By that I mean turning off the debugger and not trick the system by stubbing it out.
Same for access to Transcript. There shouldn't really be *any* direct reference to Transcript to begin with, but rather a small but effective logging API, e.g. Josef's toothpick.
We Smalltalkers (I just happen to reply to Igor here, I'm including myself in this remark too ;-) ) tend to use magic tricks just because we can, but that doesn't mean it is good engineering.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Oct 29, 2008 at 08:12:31AM +0100, St?phane Ducasse wrote:
I'm still looking for people to help cleaning the PopUpMenu plague.
the idea would be to change PopUpMenu -> ToolBuilder but this is not the solution. the PopUpMenu should be converted into a Warning and lot of PopUpMenu should be removed.
What do you mean by "PopUpMenu plague"? I assume you mean refactoring Parser to send exceptions up the stack rather than interacting itself, and moving all that interaction code somewhere else (Where?). Is there anything else you mean? Does NewParser solve this problem, at least partially? -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
I mean that we should not have reference to PopUpMenu from everywhere and especially package that are more core than UI. Stef On Oct 29, 2008, at 5:06 PM, Matthew Fulmer wrote:
On Wed, Oct 29, 2008 at 08:12:31AM +0100, St?phane Ducasse wrote:
I'm still looking for people to help cleaning the PopUpMenu plague.
the idea would be to change PopUpMenu -> ToolBuilder but this is not the solution. the PopUpMenu should be converted into a Warning and lot of PopUpMenu should be removed.
What do you mean by "PopUpMenu plague"? I assume you mean refactoring Parser to send exceptions up the stack rather than interacting itself, and moving all that interaction code somewhere else (Where?).
Is there anything else you mean? Does NewParser solve this problem, at least partially?
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
well, to be fair Pavel didn't ask a question. it was a statement that direct class referencing in this context was wrong. For specific problems or use cases, by all means use some indirection. I'm just not convinced about the generalisation. thanks, Mike
participants (8)
-
Antony Blakey -
Gary Chambers -
Igor Stasenko -
Matthew Fulmer -
Michael Roberts -
Michael Rueger -
Pavel Krivanek -
Stéphane Ducasse