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)