<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
On 12 Jun 2013, at 13:14, Galder Zamarreņo <<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>> wrote:<br>
<br>
><br>
><br>
> On Jun 10, 2013, at 12:01 PM, Adrian Nistor <<a href="mailto:anistor@redhat.com" target="_blank">anistor@redhat.com</a>> wrote:<br>
><br>
>> 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'?<br>
>><br>
>> We already document there's a (very common-sense) exception for conditional writes were the flag is ignored (ISPN-3141).<br>
><br>
> I wonder if anyone noticed my reply earlier...<br>
><br>
> "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."<br>
><br>
> 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**.<br>
<br>
</div>this would be the elegant way of doing it.<br>
<div><br></div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><div>Maybe it's worth making other flags "type-safe", but I don't think it's worth doing it for IGNORE_RETURN_VALUES.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
><br>
> 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.<br>
><br>
> [1] <a href="https://issues.jboss.org/browse/ISPN-2201" target="_blank">https://issues.jboss.org/browse/ISPN-2201</a><br>
</div>I've update the JIRA to track the fact that IGNORE_RETURN_VALUES + get should not be possible.<br>
<div><br>
Cheers,<br>
--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
<br>
<br>
<br>
<br>
<br>
</div><div><div>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>