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.