[Pharo-project] ToolSet -> ToolRegistry
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. Also, during copying a StandartToolSet convenience methods implementation i discovered a lot of tools which support different protocols. It would be nice to at least make them all respond to same message, like #open. Because currently, if you take a look at different #openXXXXX methods in ToolRegistry, its using many different/weird selectors to do the simplest possible thing - open a new window! In attachments you can find the actual class, and a small changeset which is required to make magic 'Smalltalk tools' working. I decided to put default tools/inspectors types in Preferences class. See Preferences class>>registerPreferredTools method in changeset. -- Best regards, Igor Stasenko AKA sig.
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/
2008/10/29 Matthew Fulmer <tapplek@gmail.com>:
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.
participants (2)
-
Igor Stasenko -
Matthew Fulmer