[infinispan-dev] Making confusion between different remove() APIs

[Manik Surtani]

I see your point Sanne. I wonder if it would be safe to assume that no  
one in their right minds would cache Flag instances, and in remove 
(object, object) we test the 2nd param to see if it is a flag and  
dispatch accordingly.

Sent from my iPhone

On 31 Oct 2009, at 16:37, Sanne Grinovero <sanne.grinovero at gmail.com>  
wrote:

> Hello,
> I was writing this code:
>
>   boolean cleared = cache.remove(key);
>
> and then I'd thought "let's add a Flag", resulting in:
>
>   boolean cleared = cache.remove(key, Flag.SKIP_CACHE_STORE);
>
> Considering that CacheDelegate contains the following 3 overloaded
> "remove" methods:
>
>         ====== CacheDelegate<K,V> ======
>
> public final boolean remove(Object key, Object value) {
>      return remove(key, value, (Flag[]) null);
> }
>
> public final boolean remove(Object key, Object oldValue, Flag...  
> flags) {
> ...
> }
>
> public final V remove(Object key, Flag... flags) {
> ...
> }
>         ====== end code snippet ======
>
> Guess which one is called?
> The first one, interpreting my Flag as a value, and obviously my code
> was broken.
>
> It's fixed by using:
>
> cache.remove(keyOfLock, new Flag[]{Flag.SKIP_CACHE_STORE});
>
> IMHO it's quite bad already that the CHM has different remove
> variants, one returning the previous object and one returning a
> boolean "removed or not removed", but this API in Infinispan is making
> it even harder.
> It would be safer to mandate the array form for Flags, even if I don't
> like that; do you have a better idea?
>
> Regards,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev