[jbosscache-dev] Node.getChildren()

[Manik Surtani]

Hi Ben.

Again, this (rather poor) implementation was just to get the API  
contracts in place.  It does need refactoring in the way it is  
implemented, but I see what you mean about getChildren() returning a  
Map<Fqn, Node> being more useful than returning a Collection<Node>.   
The latter (and current impl) is cleaner from an OO perspective, but  
if the former is more practical then so be it.

Just so I understand the use case better, why do you need a Map<Fqn,  
Node>?  If you are looking for a specific child, wouldn't getChild 
(Fqn) suffice?

Cheers,
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 4 Sep 2006, at 04:32, Ben Wang wrote:

> Manik,
>
> I have noticed that this is the current implementation for  
> Node.getChildren():
>
>
>    public Collection<Node> getChildren()
>    {
>       Map m = currentNode.getChildren();
>       Set<Node> children = new HashSet<Node>(m.size());
>       Iterator i = m.values().iterator();
>       while (i.hasNext())
>       {
>          children.add(new TreeCacheProxyImpl(treeCache, (NodeImpl)  
> i.next()));
>       }
>
>       return children;
>    }
>
>
> Actually, what I need now is a map of (keyFqn, node), i.e., return  
> m. But even if we stick to this api, creating children will be  
> quite expensive won't it be if getChildren is called many times  
> (happens for my case dealing with Collection classes).
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev