If you add a morph to another morph then you need to delete it.
opening in world is essentially adding the morph to the paste up morph the represents the world.
If the morph is not known by any other morph it will be gc'ed. But there are a lot of ways it could be known, not only as a submorph. Local methods for deletion might also be removing those extra links.
So to answer your question. In some circumstances deletion may not be necessary. Usually it will always be sufficient.
> http://wiki.squeak.org/squeak/428 says:
> When you create Morphs, even if you do not do an openInWorld, you should
> delete them.
> aPatchArchiveClient delete
> However, the method comment for Morph>>delete is:
> "Remove the receiver as a submorph of its owner and make its
> new owner be nil."
> If the morph was not opened in the world, won't the owner of the top-level
> morph already be nil? I want to update either the wiki or the comment to be
> in sync, but I'm not sure which is right.
Look for implementers of #delete - quite a few Morph subclasses override it to do some cleanup.
> From: Sean P. DeNigris <[hidden email]>
> Subject: [Newbies] Re: Deleting unopened morphs after unit tests
> To: [hidden email] > Date: Wednesday, June 16, 2010, 9:05 PM
> Jerome Peace wrote:
> > Local methods for deletion might also be removing
> those extra links.
> What do you mean by "local methods for deletion?"
Just what bert said. A method for a morph subclass that overides or extends the inherited method. I just said it in an unusual way.
> Jerome Peace wrote:
> > So to answer your question. In some circumstances
> deletion may not be
> > necessary. Usually it will always be sufficient.
> So as long as no one outside the test method is holding a
> reference to
> either an owner morph or any of its submorphs, there's no
> need to delete any
> of them, right?
The answer is it depends on the morph. Why are you trying to outguess the standard protocol? Any gain in speed is lost in having the test depend on the morph in question not doings anything special when deleted. Wouldn't this make the test rigid and fragile?
When I write morph tests with examples I set up a testcases ivar with a list. In the test anything that needs deleting is added to the list.
The tear down iterates over the list deleting the morphs then nils out the ivar .
Since I'm lazy I do this for one test class and sub class other test classes to that one when such behavior is needed.