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

[Manik Surtani]

Hmm that won't work either since the return type breaks.

Also you only have this problem when you specify just one flag. The  
moment there is more than one flag the vararg signature resolves  
properly.

This does suck though... I suppose log a warning when we detect a Flag  
passed in as a value and recommend that people use the array form for  
this case?

Sent from my iPhone

On 3 Nov 2009, at 12:25, Manik Surtani <manik at jboss.org> wrote:

> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev