[jbosscache-dev] Node.getChildren()

[Manik Surtani]

Like I said, depends on your usage.  If you get a hold of the key set  
and entry set and then iterate through these, you may as well iterate  
through a collection of nodes.  :)
--
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 5 Sep 2006, at 01:24, Ben Wang wrote:

> For CachedMaplImpl, I have been relying on keySet() and entrySet()  
> from the returned Map to get Fqn, Node Collection. Yes, I can  
> create it myself from the returned Collection by looping. But it  
> will do the extra work from your fresh Collection instance, will it  
> not?
>
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik at jboss.org]
> Sent: Tuesday, September 05, 2006 12:06 AM
> To: Ben Wang
> Cc: jbosscache-dev at lists.jboss.org
> Subject: Re: [jbosscache-dev] Node.getChildren()
>
> So if you don't know the Fqn in advance, how does having a Map<Fqn,
> Node> help over having a Collection<Node>?  The only benefit I can
> see here is doing Map<Fqn, Node>.containsKey()... all else should  
> be just as easy/efficient with Collection<Node>, IMO.  Am I missing  
> something?
>
>
> --
> 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 17:01, Ben Wang wrote:
>
>> 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 at jboss.org]
>> Sent: Monday, September 04, 2006 7:14 PM
>> To: Ben Wang
>> Cc: jbosscache-dev at 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 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
>>
>