Re: Weak pointers

Wolfgang Lux (lux@heidelbg.ibm.com)
Tue, 18 Mar 97 18:32:21 +0100

Message-Id: <9703181732.AA59886@idse.heidelbg.ibm.com>
To: Kohler Markus <kohlerm@betze.bbn.hp.com>
Subject: Re: Weak pointers
In-Reply-To: (Your message of Tue, 18 Mar 97 16:37:42 GMT.)
<199703181637.RAA27735@betze.bbn.hp.com>
Date: Tue, 18 Mar 97 18:32:21 +0100
From: Wolfgang Lux <lux@heidelbg.ibm.com>

[...]
> > > =

> > > IMHO the real solution is to implement a delete method for the tree=
whcih =

> > > takes care of all that internal pointers. =

> > > =

> > =

> > No. The delete method for the tree is the wrong place. You would link=
=

> > your tree implementation hardly with the use of the hash table and =

> > disallow the use of the data structure without a hash table or with =

> > another hash table implementation. This does not seem good software =

> > engineering practice to me.
> >
> =

> That's no problem. In some sense this Tree is not a Tree but some kind =
of =

> directed graph. This graph datastructure could use a hash table and a t=
ree by =

> aggregation for example.

> =

> There's n reason why this datastructures has to use a specific hash tab=
le. =

You are right.

> =

> If one deletes a node in graph this means that ALL references to the no=
de hav =

> to be deleted. =

> =

But this may no be the thing you want to do! Consider the case where an =

element might occur more than once in a tree. If you remove one =

reference in the tree you cannot simply call delete because the other =

references in the tree might be perfectly valid. But if the last such =

reference is removed from the tree you also want to be able to release =

the memory of the data structure without regard to the fact that the =

element is still referenced from the hash table. In your proposal =

either the user would have to make sure that he knows whether (s)he is =

removing the last reference from the tree or not and calling a =

different function in both cases, or the function which removes an =

element from the tree has to count the number of references in the tree =

and call delete in that case.

[...]
> This also has to do with the finalization mechanism. If a finalize meth=
od is =

> called when the object is destroyed, the object could tell all it's dep=
ends " =

> "hey I'm going to be deleted". =

OK. But as long as there is a reference to object (and there is one throu=
gh the hash table) the object won't be destroyed. The point here is that =
the status of a reference through the tree is different from the referenc=
e through the hash table pointer. IMHO your proposed data structure canno=
t be a simple aggregation of a tree and a hash table in that case.

Regards
Wolfgang

----
Wolfgang Lux WZH Heidelberg, IBM Germany
Phone: +49-6221-59-4546 Fax: +49-6221-59-3500
Internet: lux@heidelbg.ibm.com Office: mazvm01(lux)