Morph>delete

Eric Arseneau eat at huv.com
Fri Sep 8 20:56:34 UTC 2000


Bob is right.

> Also, I don't really see the need for also removing submorphs in the first
> place, because if only the deleted morph holds references to
> them, and it is
> permanently sent into oblivion, then gc will eat them too. This is the
> normal Smalltalk semantic for deleting imho. In other words, the semantic
> expectation widely thought to have been described by Tim.

The fact that we have a GC, does not mean that there is no need for cleaning
up after one's self.  There are other types of memory leaks that can occur,
GC's simply allow you to not use memory that has been de-allocated already.
Objects only get GC'ed when there is no longer a reference to the.  Lets
take simple example, I have a morph down in the submorph tree that has
registered itself as a dependent on some other object, let's call this other
object MyService or something.  When the submorph was created, it asked
MyService to notify it of a certain event.  In order to do this, MyService
keeps a handle to the submorph and sends it messages at the appropriate
time.  Now, MyService happens to be something that hangs around for a long
time, as it is part of my login process or something like that.  If I delete
an ancestor of this submorph, due to the user closing it down or something,
then the submorph is still held onto by MyService.  Now, lets go further and
see I happen to create another of these submorphs, I now have two of them
hanging around.  Not until MyService is shut down will these submorphs be
removed.  This is BAD, its called a memory leak.

Now, you could say that MyService should use a Weak type of reference, and
therefore the problem goes away.  Not so fast.  What if the ONLY reference
intended for a particular object is this dependency ?  IE, some object
creates itself, and lets itself be pointed to by MyService, and only wants
to go away when MyService does.  Then the weak structure is a problem.

And again, you could say, lets have weak and strong dependencies.  I don't
really have a good argument against that, other than I disagree with some of
what you say below.  A GC does not imply that one no longer has to worry
about objects lying around, the problem is still there.

> To remove the submorphs would seem to be the equivalent of nil:ing out the
> fields of an object which no other object referenced in the first place
> anyway.

Every time you set up a dependency betwen objects, they must be released.
That is what the release method is all about, removing any external
dependencies to me I have established during my lifetime.

>
> What was the context that made <the original poster> need this additional
> submorph deletion in the first place?

I hope this helps to answer the question.





More information about the Squeak-dev mailing list