FAQ: Deleting a Morph
Last updated at 6:29 am UTC on 6 May 2019
Stephane Ducasse asked: How to I delete a morph definitively?
Bob Arning answered:
The notion of "deleting" a morph is one that often causes some confusion. In the Morphic world, #delete simply means that the receiver is to be disconnected from its owner (the receiver is removed from its owner's submorphs collection and the receiver's owner is set to nil). The first effect of this action is that the morph is no longer drawn when its former owner is redrawn. Thus the morph visually disappears from the world. The second effect is, usually, that the morph will soon be garbage collected. I say usually since garbage collection is based on removing objects that are no longer references and the owner of a morph is usually the sole referencekeeping the morph alive.
The trash can.
If your preferences are set to put morphs deleted with the pink halo in the trash (so you can get them back if you realize you've made a mistake), then the trash can will be keeping them alive.
You can see what's there from World/authoring tools.../view trash = contents. You can also empty the trash by a similar menu path.
Finally, you can change your preferences so that things are not put into the trash: World/help/preferences/morphic/ then set "preserveTrash" to false.
Sometimes one morph is made dependent on another and for many morphs this means using the DependentsFields dictionary to store the dependency. If the dependency is not explicitly broken, then the morphs in question will not be garbage collected. Inspect DependentsFields to see if your morphs are listed there.
(Fortunately, as of Squeak 3.1alpha, DependentsFields is now a "weak" dictionary, which means that these dependents will automatically get garbage collected without you having to break the dependencies.)
Your morph might be kept around by the undo feature. The CommandHistory's lastCommand has been known to keep a reference to your undead morph.
You may have created other references. If you store a morph in a class variable, for example, that morph will not be garbage collected.
A common example of this is wanting no more than one copy of a give morph at a time. You might create a class variable to remember when you create one so you don't create a second one. The problem would occur if you failed to clear the class variable when you deleted the morph.
I saw 'abandon': I had expected that 'Morph>>delete' and 'Morph>>abandon' would be different or at least that one of the two really delete cleanly the morph.
"abandon" is intended for subclasses to add additional behavior that they need. In some cases that might include your notion of "cleanly deleting the morph". What would probably help you is to step away from the notion of cleanly deleting anything and ask instead why that object is still around. One way is to evaluate
PointerFinder on: MyMorph allInstances first
another is to use the menu in the inspector to find references to the inspected object (note: this can involved many levels and false trails before finding the real reason).
Morph - common messages