I find this method broken and sad:
"Answer the inspector class for the given object. The tool set must know which inspector type to use for which object - the object cannot possibly know what kind of inspectors the toolset provides."
| map |
map := Dictionary new.
map at: spec first put: spec last.
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
Is this really to be preferred over sending inspectorClass to the object? This method is bad because it is a point of collision for anyone who wants to add a custom inspector. Hence it creates unnecessary conflicts between packages, whereas implementing inspectorClass allows one to keep things separated.
The late binding/defaulting the use of the class name and classNamed: provides here could be achieved by implementing Object>>inspectorClassName just as easily as this hard-wired table.
From the name ToolSet, I understand that the goal was to provide several different sets of inspectorClass. Whether it is really usefull or not I don't know, but you are right, the implementation is ruining extensibility. A visitor pattern, inspectorClassForToolSet: aToolSet ^aToolSet inspectorClassForCompiledMethod could help if we really want programmable ToolSet. Do we?
Le 5 févr. 2018 19:43, "Eliot Miranda" <[hidden email]> a écrit :
In reply to this post by Eliot Miranda-2
well, this seems wrong. :) We have Object >> #inspectorClass but it is only used in Inspector >> #inspect:. We should change StandardToolSet >> #inspect: etc. to make use of #inspectorClass. Then, we should just delete #inspectorClassOf:.
On Feb 5, 2018, at 12:26 PM, Marcel Taeumel <[hidden email]> wrote:
I'll take a look at it.
|Free forum by Nabble - Resume Templates||Edit this page|