RE: [jbosscache-dev] Node.getChildren()
In my case, I am querying for all children Node and find out their respective (fqn, Node).
Problem is that I don't know the fqn in advance. I am using this currently for
Collection implementation for keySet and entrySet, for example.
Cheers,
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, September 04, 2006 7:14 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: 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