Morph class>>initializedInstance used to say: ************* 'From Squeak3.3alpha of 30 January 2002 [latest update: #4816] on 3 May 2002 at 2:59:36 pm'! !Morph class methodsFor: 'new-morph participation' stamp: 'efo 5/3/2002 14:59'! initializedInstance "Answer an instance of the receiver which in some sense is initialized. In the case of Morphs, this will yield an instance that can be attached to the Hand after having received the same kind of basic initialization that would be obtained from an instance chosen from the 'new morph' menu. Return nil if the receiver is reluctant for some reason to return such a thing"
^ (self class includesSelector: #descriptionForPartsBin) ifTrue: [self newStandAlone] ifFalse: [self new initialize]! ! ^^^^^^^^^^ *************
but Morph class>>new says: ************* 'From Squeak3.3alpha of 30 January 2002 [latest update: #4816] on 3 May 2002 at 2:59:49 pm'!
!Morph class methodsFor: 'instance creation'! new
^ super new initialize! ! ^^^^^^^^^^ *************
So I removed 'initialize' from Morph class>>initializedInstance Is it ok?
Emilio
Oca,
Yes, you are correct. Your fix has now been published (to the internal servers) as update 4858initInstFix-efo.
Reasons this bug did not attract notice before:
(1) It only arose when the little-known "sample instance" menu item was used to get a new morph. This item is buried in the "more..." (shifted) menu that you find in class-list menus and message-list menus in the various code tools.
"Sample instance" provides a way to get a morph "directly from a browser." If you are looking at the code of some morph class in a browser, you can directly launch a sample instance so you can have a live object to accompany your code exploration. For example, you can then immediately open an Inspector on the object, and use its bottom pane to send it some of the actual messages you're looking at.
(2) It only arose when the sample-instance requested was for a morph subclass that had not "registered". That would make it either a morph type not capable of standing on its own, or else a morph class that had not yet caught up with the need to implement the one method that it takes to make it a "citizen" of the population of launchable morphs. (There are rather few such laggards remaining -- and anyone who finds one can serve the common good here by implementing and contributing a #descriptionForPartsBin method for it.)
(3) And it would only be *noticeable* if having #initialize called twice on the nascent instance had a perceptibly different effect from calling it once. Most likely something like a halt or a write to the Transcript that was temporarily put into an #initialize method, I would guess.
Thanks for finding this!
-- Scott
At 3:33 PM -0300 5/3/02, Oca Emilio wrote:
Morph class>>initializedInstance used to say:
'From Squeak3.3alpha of 30 January 2002 [latest update: #4816] on 3 May 2002 at 2:59:36 pm'! !Morph class methodsFor: 'new-morph participation' stamp: 'efo 5/3/2002 14:59'! initializedInstance "Answer an instance of the receiver which in some sense is initialized. In the case of Morphs, this will yield an instance that can be attached to the Hand after having received the same kind of basic initialization that would be obtained from an instance chosen from the 'new morph' menu. Return nil if the receiver is reluctant for some reason to return such a thing"
^ (self class includesSelector: #descriptionForPartsBin) ifTrue: [self newStandAlone] ifFalse: [self new initialize]! ! ^^^^^^^^^^
but Morph class>>new says:
'From Squeak3.3alpha of 30 January 2002 [latest update: #4816] on 3 May 2002 at 2:59:49 pm'!
!Morph class methodsFor: 'instance creation'! new
^ super new initialize! ! ^^^^^^^^^^
So I removed 'initialize' from Morph class>>initializedInstance Is it ok?
Emilio
Content-Disposition: attachment; filename="Morph class-initializedInstance.st"
squeak-dev@lists.squeakfoundation.org