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

[Sanne Grinovero]

+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.

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