On Jun 13, 2013, at 2:40 PM, Dan Berindei <[email protected]> wrote:
> > On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus <[email protected]> wrote: > > On 12 Jun 2013, at 13:14, Galder Zamarreño <[email protected]> wrote: > > > > > > > On Jun 10, 2013, at 12:01 PM, Adrian Nistor <[email protected]> wrote: > > > >> Maybe we could just clarify the javadoc of IGNORE_RETURN_VALUES and say > >> that it only applies to write operations and is ignored for everything > >> else? Why punish the user with an exception when doing a 'get'? > >> > >> We already document there's a (very common-sense) exception for > >> conditional writes were the flag is ignored (ISPN-3141). > > > > I wonder if anyone noticed my reply earlier... > > > > "The flag business does need a big re-think. Not only to separate internal > > from external flags (we have a jira for that [1]), but also to have a way > > to define which flags can be passed to a particular operation, in a way > > that's type-safe, and without resulting in a runtime error of the likes of > > "X flag cannot be used with Y operation". IOW, any error on which flag can > > be used with what operation should ideally be caught at compilation time. I > > don't have specific ideas on this right now, but I think it'd be good to > > achieve this." > > > > IOW, I suggest we leave it as it is. We need to re-think it anyway. So > > let's tackle it in 6.0 so that a get operation can never be passed > > IGNORE_RETURN_VALUES flag, and this being something that's caught at > > **compilation time**. > > this would be the elegant way of doing it. > > > An even more elegant solution would be to make put return void by default, > and force the user to state explicitly that he wants a return value - a la > JSR-107. I know that would break backwards compatibility, so it may not be an > option even in 6.0, but still I think we should focus on that. > > Maybe it's worth making other flags "type-safe", but I don't think it's worth > doing it for IGNORE_RETURN_VALUES. Fair point. I hope once JCache (JSR-107) is final we can move towards making their Cache API the main entrance point and reduce our Cache to having only those methods not present in JCache. > > > > > > I'm just about to add another internal flag to Flag as a result of the > > JCache 0.7 upgrade…, so need to tackle ISPN-2201 to avoid causing more > > confusion, and alongside avoid the issues that have been highlighted WRT > > which operations are allowed which flags. I'm happy to do this for 6.0. > > > > [1] https://issues.jboss.org/browse/ISPN-2201 > I've update the JIRA to track the fact that IGNORE_RETURN_VALUES + get should > not be possible. > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
