Re: [Pharo-project] Toolset vs UIManager
+150 !! UIManager is the Utilities of Morphic ^^ I sent an email about restructured it but I haven't got any answer. I think that UIManager was a good idea at the beginning. It's a bag of UI which can be used by every classes to avoid duplications. The maor problem with that is that the implementations of methods are done with too hight tool, and then there is tons of bad dependencies. Jannik and I was discussing about create multiple polymorphic UIManager classes implementd with different level of morphic tools. This way, yo can plug and unplug PolyMorph or things like that. ToolSet is pretty much the same about Tools but with the specificity to inherits from AppRegistry which allow you to switch between classes providing tools. But it's not used. Ben On Dec 3, 2010, at 10:52 PM, Francisco Ortiz Peñaloza wrote: +2 :) On Fri, Dec 3, 2010 at 6:41 PM, Esteban Lorenzano esteba...@gmail.com wrote: +1 El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió: On 3 December 2010 21:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: I was reading the change of benjmain to deprecate notifyWithLabel: aString from Object. Yes! Now he was putting it on ToolSet and I thought that I would have put it on UIManager. Now the relationship and responsibility of this two classes are not clear to me. Does anybody a clear thought on that? they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Toolset vs UIManager
Ok this sounds like a good idea. So we should do that. Now I would like to have a clear comment in both classes and avoid duplicated code or functionality. Stef they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Toolset vs UIManager
On 3 December 2010 21:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: I was reading the change of benjmain to deprecate notifyWithLabel: aString from Object. Yes! Now he was putting it on ToolSet and I thought that I would have put it on UIManager. Now the relationship and responsibility of this two classes are not clear to me. Does anybody a clear thought on that? they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Toolset vs UIManager
+1 El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió: On 3 December 2010 21:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: I was reading the change of benjmain to deprecate notifyWithLabel: aString from Object. Yes! Now he was putting it on ToolSet and I thought that I would have put it on UIManager. Now the relationship and responsibility of this two classes are not clear to me. Does anybody a clear thought on that? they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Toolset vs UIManager
+1 This also will permit to redirect all the messages like inform and progress bars to log files, instead than ui windows. This would be analog to the work Dale did for the Metacello silent way of installing. Cheers El vie, 03-12-2010 a las 18:41 -0300, Esteban Lorenzano escribió: +1 El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió: On 3 December 2010 21:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: I was reading the change of benjmain to deprecate notifyWithLabel: aString from Object. Yes! Now he was putting it on ToolSet and I thought that I would have put it on UIManager. Now the relationship and responsibility of this two classes are not clear to me. Does anybody a clear thought on that? they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig. -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Re: [Pharo-project] Toolset vs UIManager
+2 :) On Fri, Dec 3, 2010 at 6:41 PM, Esteban Lorenzano esteba...@gmail.comwrote: +1 El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió: On 3 December 2010 21:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: I was reading the change of benjmain to deprecate notifyWithLabel: aString from Object. Yes! Now he was putting it on ToolSet and I thought that I would have put it on UIManager. Now the relationship and responsibility of this two classes are not clear to me. Does anybody a clear thought on that? they are related but still a bit different. a toolset provides an access to standard system tools like browser, inspector debugger etc. while UI manager provides an access to things like inform:, progress bars etc My proposal remains same as before. i proposed to unify this API and use idioms like: Smalltalk tools browser openOn: aClass as well as Smalltalk ui inform: 'you banned' so, then we don't need to have a distinct classes, but instead a roles, like 'tools' , 'ui', 'browser' which should support corresponding protocol. Stef -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] ToolSet
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 [EMAIL PROTECTED]: 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ToolSet
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ToolSet - ToolRegistry
On Wed, Oct 29, 2008 at 04:20:55AM +0200, Igor Stasenko wrote: I'm implemented a new ToolRegistry class, which can work as replacement of ToolSet. It would require a 'bit' refactoring, to replace all references to 'ToolSet' with 'Smalltalk tools'. What i discovered during implementation, if we migrate to new class, a lot of stuff can be cleaned up. For instance, Smalltalk tools inspectorTypes holds a dictionary of Class name - inspector class name so, one could simply register own inspector by including a line: Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector in package/class initialization method, instead of overriding #inspect method. Actually, you are supposed to override inspectorClass, but yes, that does sound more uniform. Does it support inheritance, so that subclasses of MySpecialClass will use the nice inspector too? I don't see anything wrong with inspectorClass, except for the fact that ObjectExplorer and Inspector don't share the same inspection model, which means you see different things when exploring vs inspecting a CompiledMethod -- 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
Re: [Pharo-project] ToolSet - ToolRegistry
2008/10/29 Matthew Fulmer [EMAIL PROTECTED]: On Wed, Oct 29, 2008 at 04:20:55AM +0200, Igor Stasenko wrote: I'm implemented a new ToolRegistry class, which can work as replacement of ToolSet. It would require a 'bit' refactoring, to replace all references to 'ToolSet' with 'Smalltalk tools'. What i discovered during implementation, if we migrate to new class, a lot of stuff can be cleaned up. For instance, Smalltalk tools inspectorTypes holds a dictionary of Class name - inspector class name so, one could simply register own inspector by including a line: Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector in package/class initialization method, instead of overriding #inspect method. Actually, you are supposed to override inspectorClass, but yes, that does sound more uniform. Does it support inheritance, so that subclasses of MySpecialClass will use the nice inspector too? Yes, it supports inheritance in same way as old model (but it was not extensible). E.g. if you have ClassA and ClassAInspector, then ClassB which is subclass of ClassA will use ClassAInspector. This is not the only uniformity which provides new model. There are a number of classes, like UIManager which using classvar to hold their 'default' sole instance. Now with ToolsRegistry we can use a single storage for all such singletons. So, instead of: UIManager default or SystemBrowser default we can refactor to: Smalltalk tools uiManager and Smalltalk tools browser It is also more convenient from customization perspective: all preferences are gathered into single place, so you don't need to search throughout image to dig out where is some preference stored and how to change it, in case of need. Moreover, different packages can register own tools, or replace existing ones. I don't see anything wrong with inspectorClass, except for the fact that ObjectExplorer and Inspector don't share the same inspection model, which means you see different things when exploring vs inspecting a CompiledMethod Yes, explorer using different model for displaying object(s). As i remember it is using a common #printOn: message to display objects. -- 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 -- 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
Re: [Pharo-project] ToolSet
2008/10/28 Pavel Krivanek [EMAIL PROTECTED]: 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
Re: [Pharo-project] ToolSet
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ToolSet
2008/10/28 Michael Roberts [EMAIL PROTECTED]: 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ToolSet
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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
Re: [Pharo-project] ToolSet
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 [EMAIL PROTECTED]: 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
Re: [Pharo-project] ToolSet
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
Re: [Pharo-project] ToolSet
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 [EMAIL PROTECTED]: 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
