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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org&gt; 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(a)gmail.com&gt; > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 3 Nov 2009, at 16:31, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 3 Nov 2009, at 16:31, Emmanuel Bernard&lt;emmanuel(a)hibernate.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 3 nov. 09, at 19:03, Galder Zamarreno wrote: > > > On 11/03/2009 05:37 PM, Manik Surtani wrote: >> On 3 Nov 2009, at 16:31, Emmanuel Bernard&lt;emmanuel(a)hibernate.org&gt; >> 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? > > Interesting idea Emmanuel, seems like you're quite fond of fluent > APIs :) > > I'd stick with single word flags(), i.e.: > > cache.flags(FOO,BAR).remove(key) > > flags() looks explicit enough to me. The reason I use usingContext() is for future extensibility. I don't know your API well enough to know if that's necessary. Do you need both flags and hints for example? Do they apply for a single operation or many operations? In the latter case I would do Cache cache = CacheManager .usingContext() .flags(BOO) .hints("faster") .getCache(); _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Dnia wtorek 03 listopad 2009 o 17:37:53 Manik Surtani napisał(a): >> 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? Yeah, I like it too :)

-KS _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Nov 4, 2009, at 4:35 PM, Krzysztof Sobolewski wrote: > Dnia wtorek 03 listopad 2009 o 17:37:53 Manik Surtani napisał(a): >>> 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? > > Yeah, I like it too :) Yeah, me too. Emanuel, we needed you when we came up with the JBC InvocationContext API! ;) This does much the same thing but in a much more understandable way. > -KS > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev