Deleting unopened morphs after unit tests

http://wiki.squeak.org/squeak/428 says:
  When you create Morphs, even if you do not do an openInWorld, you should delete them.
    ...
    tearDown
      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.

Thanks.
Sean

Hi Sean,

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.

Yours in curiosity and service, --Jerome Peace

--- On Wed, 6/16/10, Sean P. DeNigris <[hidden email]> wrote:



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 17.06.2010, at 00:02, Sean P. DeNigris wrote:

Look for implementers of #delete - quite a few Morph subclasses override it to do some cleanup.

So the advice to call it is good.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Jerome Peace wrote

Local methods for deletion might also be removing those extra links.

What do you mean by "local methods for deletion?"

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?

Thanks.
Sean

--- On Wed, 6/16/10, Sean P. DeNigris <[hidden email]> wrote:

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

Keep up the good work.

Yours in curiosity and service, --Jerome Peace

     
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners