[prev in list] [next in list] [prev in thread] [next in thread]
List: groovy-user
Subject: Re: [groovy-user] Inconsistent behaviour of &,|, || and && operators
From: Marcin Gryszko <marcin () grysz ! com>
Date: 2013-09-29 11:30:07
Message-ID: CABH-wkwtMAaQb994ENWxviHcCx-zBmbq2pU5QFRkCJQKFcdjcg () mail ! gmail ! com
[Download RAW message or body]
After reading thoroughly the thread, I agree with Jim. Thanks also to Paul
for a nice summary.
On Sep 26, 2013 4:54 PM, "Paul Bennett" <paul@prajnainc.com> wrote:
> As a somewhat impartial observer here, and as another user from the
> community, I agree with Jim on this issue. I would put it like this:
> Thinking that
>
> true | null
>
> should evaluate to true because
>
> true || null
>
> does is a mistake, because | and || are *different kinds of operators*. |
> is a binary operator on bit-oriented data, and || is a logical one, on
> logical values. They treat their operands as different types, and
> *interpret them (the bit pattern) in different ways*. And thus produce -
> correctly - different results. To me, true | null means ' take the bit
> representation of the LHS and bitwise OR it with the RHS'. 'null' is a
> conceptual value, and it's bit representation undefined (which could also
> apply to 'true', since under Groovy Truth, 'true' and 'false' have many
> different representations). Therefore, the expression is meaningless, and
> an NPE an acceptable result for trying to execute it. It's an
> implementation specific way of saying 'this makes no sense' (I would also
> argue that a better response to 'true | null" would be to throw an
> UnsupportedOperationException, but that's really a different issue).
>
> This is perfectly consistent with
>
> 1 | null
>
> and
>
> 1 | 2,
>
> the first of which gives an NPE (and again, is meaningless), and the
> second of which produces 3
>
> I believe I'm saying the same thing as Jim, just in a different way.
>
> -pb
>
>
>
> On Sep 24, 2013, at 12:51 PM, Jim White wrote:
>
> Resolved not a bug.
>
> Jim
>
>
>
> On Tue, Sep 24, 2013 at 8:58 AM, Marcin Gryszko <marcin@grysz.com> wrote:
>
>> Done - http://jira.codehaus.org/browse/GROOVY-6361
>>
>
>
> -pb
>
>
>
[Attachment #3 (text/html)]
<p dir="ltr">After reading thoroughly the thread, I agree with Jim. Thanks also to \
Paul for a nice summary.<br> </p>
<div class="gmail_quote">On Sep 26, 2013 4:54 PM, "Paul Bennett" <<a \
href="mailto:paul@prajnainc.com">paul@prajnainc.com</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
style="word-wrap:break-word">As a somewhat impartial observer here, and as another \
user from the community, I agree with Jim on this issue. I would put it like this: \
Thinking that <div><br></div><div>true | null </div> <div><br></div><div>should \
evaluate to true because </div><div><br></div><div>true || null \
</div><div><br></div><div>does is a mistake, because | and || are *different kinds of \
operators*. | is a binary operator on bit-oriented data, and || is a logical one, on \
logical values. They treat their operands as different types, and *interpret them \
(the bit pattern) in different ways*. And thus produce - correctly - different \
results. To me, true | null means ' take the bit representation of the LHS and \
bitwise OR it with the RHS'. 'null' is a conceptual value, and it's \
bit representation undefined (which could also apply to 'true', since under \
Groovy Truth, 'true' and 'false' have many different \
representations). Therefore, the expression is meaningless, and an NPE an acceptable \
result for trying to execute it. It's an implementation specific way of saying \
'this makes no sense' (I would also argue that a better response to 'true \
| null" would be to throw an UnsupportedOperationException, but that's \
really a different issue).</div> <div><br></div><div>This is perfectly consistent \
with</div><div><br></div><div>1 | null</div><div><br></div><div>and \
</div><div><br></div><div>1 | 2,</div><div><br></div><div>the first of which gives an \
NPE (and again, is meaningless), and the second of which produces 3</div> \
<div><br></div><div>I believe I'm saying the same thing as Jim, just in a \
different way.</div><div><br></div><div>-pb</div><div><br><div><br></div><div><br><div><div>On \
Sep 24, 2013, at 12:51 PM, Jim White wrote:</div> <br><blockquote type="cite"><div \
dir="ltr">Resolved not a bug.<div><br></div><div>Jim</div><div><br></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 24, 2013 at 8:58 AM, \
Marcin Gryszko <span dir="ltr"><<a href="mailto:marcin@grysz.com" \
target="_blank">marcin@grysz.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Done - <a \
href="http://jira.codehaus.org/browse/GROOVY-6361" \
target="_blank">http://jira.codehaus.org/browse/GROOVY-6361</a></div>
</blockquote></div><br></div>
</blockquote></div><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-web \
kit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separ \
ate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><span \
style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-au \
to;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;te \
xt-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div \
style="word-wrap:break-word">
-pb<br><br></div></span></span>
</div>
<br></div></div></div></blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic