Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections

[Kief Morris <ki...@bitbull.com>]

Sorry for the delay in responding, too much going on outside the coding life.

Stephen Colebourne typed the following on 12:49 AM 4/2/2002 +0100
>> I would suggest it would be better to keep the list
>> holding the children better hidden from the user.
>> Children can be added and removed with methods such as
>> TreeNode.addChild() and TreeNode.removeChild(). 

>True, provided you only go down one level. By hiding the created child node,
>you cannot add any children to it, which is a bit of a problem.
...
>> A List or Collection of children can be returned from
>> TreeNode, but should be a defensive copy of the
>> internal list.

>I disagree. A dead copy means less to implement, but means we end up adding
>all the List methods to TreeNode. I would suggest that by using a live list
>of children we enable applications to use the full interface of List to
>manipulate that list of children, such as subList() and retainAll() that
>wouldn't be available otherwise. Having an addChild(TreeNode) method on
>TreeNode may well be a good idea for ease of use however.

OK, I'm still uncomfortable with the design, but I see the reasons for it. Having 
both the internal nuts and bolts interface of TreeNode and the smooth locked-down 
interface of Tree available sounds better and better the more I understand the
practicalities of your approach.

>Related to this is the question of hashCode and equals methods. (The other
>type of collection is a Set, which needs a hashCode). So far, my view is to
>use the == check for equals and the identity hashCode (ie. don't implement
>either method).

These sounds better than the alternatives you examined and rejected. Have 
you looked at how the Sun or other commons collections implement these?

>> A question, in ArrayTreeNode.toString() you use a
>> method called Reflection.getShortenedClassName(),
>> which I don't have anywhere in my system (using JDK
>> 1.3). Where does this come from?
>
>Another of my utilities is a set of reflection utilities. In this case the
>code got the class name minus the package name (which ironically doesn't use
>reflection!). Its available on joda.org if you want it, but we should really
>have a better toString() implementation anyway - more collections like -
>including a list of the children.

Yes, I agree the overhead of reflection isn't appropriate for toString. Maybe
cache the string value (list of children), and update it when new children are
added? Each node could maintain a string list of its children, and when it
changes it, trigger its parent to do the same. 

Kief


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections

[Stephen Colebourne <sc...@eurobell.co.uk>]

From: Kief Morris <ki...@bitbull.com>
> Stephen Colebourne typed the following on 12:17 AM 4/7/2002 +0100
> >I have tweaked our two sets of interfaces tonight to produce a
combination
> >that starts to hang together. I don't think I lost any functionality, but
> >they are only the interfaces at the moment. See what you think at
>
> Stephen, my personal situation right now is keeping me from getting into
> this. Why don't you go ahead with submitting TreeNode and related stuff,
> and when I get some more time (probably a few months) I'll dig back into
> this. Sorry to lame out on you.
>
> Kief

OK. I will proceed with implementing the interfaces previously posted. I
will then post the full Tree implementation for wider commons review.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections

[Kief Morris <ki...@bitbull.com>]

Stephen Colebourne typed the following on 12:17 AM 4/7/2002 +0100
>I have tweaked our two sets of interfaces tonight to produce a combination
>that starts to hang together. I don't think I lost any functionality, but
>they are only the interfaces at the moment. See what you think at

Stephen, my personal situation right now is keeping me from getting into 
this. Why don't you go ahead with submitting TreeNode and related stuff, 
and when I get some more time (probably a few months) I'll dig back into 
this. Sorry to lame out on you.

Kief


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections

[Stephen Colebourne <sc...@eurobell.co.uk>]

> >Related to this is the question of hashCode and equals methods. (The
other
> >type of collection is a Set, which needs a hashCode). So far, my view is
to
> >use the == check for equals and the identity hashCode (ie. don't
implement
> >either method).
>
> These sounds better than the alternatives you examined and rejected. Have
> you looked at how the Sun or other commons collections implement these?

List and Map both perform equals() by looping around all their contents
comparing values. As I said before, a value only comparison won't do for
TreeNode because it ignores the structure. (Something different might be
possible for Tree, because the keys enable quick access to the whole tree).

> >...we should really
> >have a better toString() implementation anyway - more collections like -
> >including a list of the children.
>
> Yes, I agree the overhead of reflection isn't appropriate for toString.
Maybe
> cache the string value (list of children), and update it when new children
are
> added? Each node could maintain a string list of its children, and when it
> changes it, trigger its parent to do the same.

I think even that is more than we need, how about
TreeNode[x children,value=y]
as a format for TreeNode's toString()?


I have tweaked our two sets of interfaces tonight to produce a combination
that starts to hang together. I don't think I lost any functionality, but
they are only the interfaces at the moment. See what you think at
http://www.scolebourne.eurobell.co.uk/Tree1.zip

Stephen




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>