Smalltalk › Squeak › Squeak - Dev

StandardToolSet class>>inspectorClassOf:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Eliot Miranda-2

StandardToolSet class>>inspectorClassOf:

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

Nicolas Cellier

Re: StandardToolSet class>>inspectorClassOf:

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

marcel.taeumel

Re: StandardToolSet class>>inspectorClassOf:

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

Eliot Miranda-2

Re: StandardToolSet class>>inspectorClassOf:

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

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

marcel.taeumel

Re: StandardToolSet class>>inspectorClassOf:

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