Re: [jbosscache-dev] Node.getChildren()
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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev