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

[Sanne Grinovero]

I've been trying different approaches, sorry I couldn't find a nice solution.

The only way I see is change all Flag... to an explicit array:

V remove(Object key, Flag... flags);
would become

V remove(Object key);
AND
V remove(Object key, Flag[] flags);

(having both signatures)
This would force the creation of an array if you want any flag, I
don't like it much.
Logging a warning would be way better than doing nothing.

2009/11/3 Manik Surtani <manik at jboss.org>:
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>