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

Galder Zamarreno galder at redhat.com
Tue Nov 3 13:04:24 EST 2009



On 11/03/2009 05:54 PM, Sanne Grinovero wrote:
> +1
> cache.withFlags(FOO,BAR).whatever()
> would be very nice, as the return type of withFlags() could still
> implement Map and ConcurrentMap, which is very cool and known to all
> developers.

If it returns org.infinispan.Cache, it definitely returns Map and 
ConcurrentMap too :)

>
> 2009/11/3 Manik Surtani<manik at jboss.org>:
>> On 3 Nov 2009, at 16:31, Emmanuel Bernard<emmanuel at hibernate.org>
>> wrote:
>>
>>> Another option is to use a fluent API
>>> blah.usingContext().flags(FOO,BAR).remove();
>>
>> Hmm, that's a possibility. Maybe cache.withFlags(FOO,BAR).remove(key)
>> where withFlags() returns a Cache.
>>
>> Wdyt, guys?
>>
>>
>>
>>>
>>> On 3 nov. 09, at 15:47, Krzysztof Sobolewski wrote:
>>>
>>>> Dnia wtorek 03 listopad 2009 o 14:24:35 Sanne Grinovero napisał(a):
>>>>> 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.
>>>>
>>>> May I drop in two other approaches?
>>>>
>>>> * Rename one of the methods to remove ambiguity altogether.
>>>> * Overload like this:
>>>> V remove(Object key);
>>>> V remove(Object key, Flag flag); // optional, would create collision
>>>> in
>>>> Cache<K, Flag>
>>>> V remove(Object key, Flag flagHead, Flag... flagRest); // unweildy
>>>> Varargs are too convenient to lose the syntactic benefits, IMO :)
>>>>
>>>> I would prefer the first option, myself. But for consistency's sake
>>>> it would
>>>> require renaming flag-taking variants of all mehods (and possibly
>>>> other
>>>> variants too).
>>>> -KS
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list