StandardToolSet class>>inspectorClassOf:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

StandardToolSet class>>inspectorClassOf:

Eliot Miranda-2
Hi All,

    I find this method broken and sad:

inspectorClassOf: anObject
"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.
#(
(CompiledMethod CompiledMethodInspector)
(CompositeEvent OrderedCollectionInspector)
(Dictionary DictionaryInspector)
(ExternalStructure ExternalStructureInspector)
(FloatArray OrderedCollectionInspector)
(OrderedCollection OrderedCollectionInspector)
(Set SetInspector)
(WeakSet WeakSetInspector)
) do:[:spec|
map at: spec first put: spec last.
].
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
].
^Inspector

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.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: StandardToolSet class>>inspectorClassOf:

Nicolas Cellier
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 :
Hi All,

    I find this method broken and sad:

inspectorClassOf: anObject
"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.
#(
(CompiledMethod CompiledMethodInspector)
(CompositeEvent OrderedCollectionInspector)
(Dictionary DictionaryInspector)
(ExternalStructure ExternalStructureInspector)
(FloatArray OrderedCollectionInspector)
(OrderedCollection OrderedCollectionInspector)
(Set SetInspector)
(WeakSet WeakSetInspector)
) do:[:spec|
map at: spec first put: spec last.
].
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
].
^Inspector

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.

_,,,^..^,,,_
best, Eliot





Reply | Threaded
Open this post in threaded view
|

Re: StandardToolSet class>>inspectorClassOf:

marcel.taeumel
In reply to this post by Eliot Miranda-2
Hi Eliot,

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:.

Best,
Marcel

Am 05.02.2018 19:43:36 schrieb Eliot Miranda <[hidden email]>:

Hi All,

    I find this method broken and sad:

inspectorClassOf: anObject
"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.
#(
(CompiledMethod CompiledMethodInspector)
(CompositeEvent OrderedCollectionInspector)
(Dictionary DictionaryInspector)
(ExternalStructure ExternalStructureInspector)
(FloatArray OrderedCollectionInspector)
(OrderedCollection OrderedCollectionInspector)
(Set SetInspector)
(WeakSet WeakSetInspector)
) do:[:spec|
map at: spec first put: spec last.
].
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
].
^Inspector

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.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: StandardToolSet class>>inspectorClassOf:

Eliot Miranda-2


On Feb 5, 2018, at 12:26 PM, Marcel Taeumel <[hidden email]> wrote:

Hi Eliot,

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:.

+1


Best,
Marcel

Am 05.02.2018 19:43:36 schrieb Eliot Miranda <[hidden email]>:

Hi All,

    I find this method broken and sad:

inspectorClassOf: anObject
"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.
#(
(CompiledMethod CompiledMethodInspector)
(CompositeEvent OrderedCollectionInspector)
(Dictionary DictionaryInspector)
(ExternalStructure ExternalStructureInspector)
(FloatArray OrderedCollectionInspector)
(OrderedCollection OrderedCollectionInspector)
(Set SetInspector)
(WeakSet WeakSetInspector)
) do:[:spec|
map at: spec first put: spec last.
].
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
].
^Inspector

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.

_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: StandardToolSet class>>inspectorClassOf:

marcel.taeumel
I'll take a look at it.

Best,
Marcel

Am 06.02.2018 00:13:56 schrieb Eliot Miranda <[hidden email]>:



On Feb 5, 2018, at 12:26 PM, Marcel Taeumel <[hidden email]> wrote:

Hi Eliot,

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:.

+1


Best,
Marcel

Am 05.02.2018 19:43:36 schrieb Eliot Miranda <[hidden email]>:

Hi All,

    I find this method broken and sad:

inspectorClassOf: anObject
"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.
#(
(CompiledMethod CompiledMethodInspector)
(CompositeEvent OrderedCollectionInspector)
(Dictionary DictionaryInspector)
(ExternalStructure ExternalStructureInspector)
(FloatArray OrderedCollectionInspector)
(OrderedCollection OrderedCollectionInspector)
(Set SetInspector)
(WeakSet WeakSetInspector)
) do:[:spec|
map at: spec first put: spec last.
].
anObject class withAllSuperclassesDo:[:cls|
map at: cls name ifPresent:[:inspectorName| ^Smalltalk classNamed: inspectorName].
].
^Inspector

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.

_,,,^..^,,,_
best, Eliot