On Jun 13, 2013, at 2:40 PM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 12 Jun 2013, at 13:14, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>
> On Jun 10, 2013, at 12:01 PM, Adrian Nistor <anistor(a)redhat.com> 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
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
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org