Hi

I hope someone will answer because I would like to know, especially 
since changeClass has never
been working in the past. And this refactoring would be nice to have. 
Keep going.

Stef

On 14 juil. 04, at 01:39, Andrew P. Black wrote:

> I'm attaching a slightly modified version of the changeset that PHK 
> submitted on 2004-07-02.  This changeset was filed-out form a traits 
> image and contains a uses: {} argument that prevents it from filing in 
> to a non-traits image.  I have removed this, and added a preamble. I 
> have made no other changes.
>
> I have noticed what appears to be a duplication of mechanism in the 
> way that the appropriate inspector is selected.
>
> (1) object>>inspect creates and inspector of a class given by the 
> method inspectorClass
>
> 		self inspectorClass openOn: self withEvalPane: true
>
> (2) However, Dictionary>>inspect and 5 other classes (CompositeEvent, 
> ExternalStructure, FloatArray, OrderedCollection and now Set) override 
> that method and specify the class of their inspector explicitly, as in
>
> 	Dictionary>>inspect
> 		"Open a DictionaryInspector on the receiver.  Use basicInspect to 
> get a normal (less useful) type of inspector."
>
> 		DictionaryInspector openOn: self withEvalPane: true
>
> (3) However, this doesn't always work.  This is because of the 
> following amazing piece of code in
>         Inspector>>inspect: anObject
> 	"Initialize the receiver so that it is inspecting anObject. There is 
> no
> 	current selection."
>
> 	| c |
> 	c := anObject inspectorClass.
> 	(self class ~= c and: [self class format = c format]) ifTrue: [
> 		self primitiveChangeClassTo: c basicNew].
> 	self initialize.
> 	object := anObject.
> 	selectionIndex _ 0.
> 	contents := ''
>
> Thus, the OrderedCollection inspector that is initially created to 
> inspect an OrderedCollection has its class forcibly changed to be 
> Inspector, because there is no #inspectorClass method in 
> OrderedCollection.
>
> I feel that I should clear away all this redundancy, and rely on the 
> #inspectorClass mechanism and Object>>inspect.  But before I do so, I 
> wondered why it was here, and what secret I'm missing.  The 
> primitiveChangeClassTo: code was added quite recently, by ajh on 
> 2003-2-3, with the comment (on the Swiki, but not in the code) that 
> "An inspector will change to the appropriate class when being updated 
> with a new receiver."  When does this happen?
>
> 	Andrew
>
>