Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39949 > unrolled thread

Understanding &&

Back to article view | Back to comp.lang.javascript

Contents

  Understanding && Andrew Poulos <ap_prog@hotmail.com> - 2021-04-16 14:30 +1000
    Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 11:00 +0100
    Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 11:17 +0000
      Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 16:09 +0100
        Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 15:26 +0000
          Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 21:09 +0100
            Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 21:06 +0000
              Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 02:01 +0100
                Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-17 08:33 +0100
                Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-17 12:06 +0100
                  Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-17 14:13 +0100
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 15:50 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-17 15:21 +0000
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 23:46 +0100
                    Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-17 23:46 +0000
                      Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 23:59 +0100
                        Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 13:56 +0000
                          Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 23:08 +0100
                            Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 22:52 +0000
                              Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-20 01:23 +0100
                                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-20 01:08 +0000
                Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-18 00:49 +0200
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:26 +0100
            Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-17 17:05 +0200
              Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 23:04 +0100
                Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-18 00:48 +0200
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:13 +0100
                    Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-19 21:58 +0200
              Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-18 18:20 +0100
            Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-18 00:40 +0200
              Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 00:14 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-18 00:01 +0000
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:44 +0100
                    Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-18 17:51 +0000
                Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-19 13:41 +0200
                  Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-19 15:02 +0100
                    Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-20 17:40 +0100
                      Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-20 18:19 +0100
                        Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-21 10:11 +0100
                          Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-21 19:46 +0100
                            Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-22 13:48 +0100
                  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 21:28 +0100
                    Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 21:56 +0000
                      Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 23:13 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#40004

On 21/04/2021 19:46, John G Harris wrote:
> On Wed, 21 Apr 2021 10:11:52 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
> 
>> On 20/04/2021 18:19, John G Harris wrote:
>>> On Tue, 20 Apr 2021 17:40:06 +0100, The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>     <snip>
>>>> specified behaviour IS convention.
>    <snip>
>> 'specified behaviour' *is* a subset of convention.
>    <snip>
> 
> Make up your mind. Are you saying
>    "IS convention",
> or are you saying
>    "*is* a subset of convention"

either will do.

convention is a set that contains specified behaviour. Therefore 
specified behaviour is (a part of, covered by, contained in) 'convention'.

In the same way that you are presumably 'human', not a 'subset of humanity'

> 
> And what if your product claims to conform to an International
> Standard? Is being honest still just a convention?

More or less it is of course. Ex of Great Sky Fairies and Cosmic 
Purpose, honesty is merely social convention . One that works well in 
large societies, especially those that trade,  but is not practised by 
e.g. Muslims outside their own diaspora. There the convention is to lie 
to unbelievers, on principle, as a moral action.

And is increasingly not practised by anyone promoting consumer 
producxts. Or renewable energyu. Or electric cars. Or political revolution

In fact honesty seems to have gone completely out of fashion. Even my 
bank lies to me these days...


Autre temps, autre moeurs....
> 
>    John
> 


-- 
“Those who can make you believe absurdities, can make you commit 
atrocities.”

― Voltaire, Questions sur les Miracles à M. Claparede, Professeur de 
Théologie à Genève, par un Proposant: Ou Extrait de Diverses Lettres de 
M. de Voltaire

[toc] | [prev] | [next] | [standalone]

#39986

Arno Welzel <usenet@arnowelzel.de> writes:

> Ben Bacarisse:
>
>> Arno Welzel <usenet@arnowelzel.de> writes:
> [...]
>>> x = a && b;
>>>
>>> Nobody would expect that this *expression* will cause parts of the code
>>> to get executed or not
>> 
>> Hmm...  Everyone should expect that since that's what && means.  Do you
>> mean && (as defined) should simply not exist is programming languages?
>
> No. It is just what I said - "a && b" is an expression which will not
> change anything in a or b because there is no additional code getting
> executed which might change a or b depending on the value of a.

I think I see what you mean, but I replied based on what you wrote.
Those extra bits about code that might change a or b weren't there.  The
"hmm..." was supposed to suggest that there is something confusing or
unlikely about what you said.

> [...]
>>> The ??= operator was *intentionally* designed to work this way.
>> 
>> That's a new one to me.  I thought the 11th edition was the latest, and
>> it's not in there.
>
> I maybe got ??= from another language, I can't remember where I looked
> this up when I mentioned it, sorry. Just forget it.

Turned out to be helpful as I learned that's it's "almost" in the
standard along with &&= and ||=.

>> That aside, I think && and || were intentionally designed to work as
>> they do, so intentional design can't justification enough in your mind.
>
> Ok, I need to clarify this:
>
> For an expression like "a && b" or "a || b" there is no obvious way how
> it will get evaluated. It's just a convetion that the evaluation will
> stop at the point where the remaining part does not *need* to be evaluated.
>
> a && b will evualate "a" first and stop, if a is false
> a || b will evualate "a" first and stop, if a is true
>
> But this is something one needs to know besides the fact that "&&" means
> "logical and" and "||" means "logical or". Therefore I call i at least
> bad style to rely on this fact and create code like

OK, I see what you mean.  I disagree, but I'm not sure that it matters
enough to say much about it.  Bottom line: programmer should know the
language, and the language does guarantee what you think of as a
convention.

> return
>   statement1 &&
>   statement2 &&
>   statement3 &&
>   statement4;

(Odd terminology.  These have to expressions, not statements.)

> instead of
>
> if (!statement1) {
>   return false;
> }
> if (!statement2) {
>   return false;
> }
> if (!statement3) {
>   return false;
> }
> return statement 4;
>
> Yes, the latter one needs more lines but is obvious what the code does
> even if you don't remember that "&&" is evaluated from left to right and
> that the the evaluation stops at the first statement which returns
> false.

Need three more lines:

  if (!statement1) {
    return false;
  }
  if (!statement2) {
    return false;
  }
  if (!statement3) {
    return false;
  }
  if (!statement4) {
    return false;
  }
  return true;

You could write return !!statement4; or return statement4 == true; but I
assume you'd rather keep the pattern going.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#39987

On 2021-04-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Arno Welzel <usenet@arnowelzel.de> writes:
>> But this is something one needs to know besides the fact that "&&" means
>> "logical and" and "||" means "logical or". Therefore I call i at least
>> bad style to rely on this fact and create code like
>
> OK, I see what you mean.  I disagree, but I'm not sure that it matters
> enough to say much about it.  Bottom line: programmer should know the
> language, and the language does guarantee what you think of as a
> convention.
>
>> return
>>   statement1 &&
>>   statement2 &&
>>   statement3 &&
>>   statement4;
>
> (Odd terminology.  These have to expressions, not statements.)
>
>> instead of
>>
>> if (!statement1) {
>>   return false;
>> }
>> if (!statement2) {
>>   return false;
>> }
>> if (!statement3) {
>>   return false;
>> }
>> return statement 4;
>>
>> Yes, the latter one needs more lines but is obvious what the code does
>> even if you don't remember that "&&" is evaluated from left to right and
>> that the the evaluation stops at the first statement which returns
>> false.
>
> Need three more lines:
>
>   if (!statement1) {
>     return false;
>   }
>   if (!statement2) {
>     return false;
>   }
>   if (!statement3) {
>     return false;
>   }
>   if (!statement4) {
>     return false;
>   }
>   return true;
>
> You could write return !!statement4; or return statement4 == true; but I
> assume you'd rather keep the pattern going.

You're kinda disproving your own point here though, since you're the one
claiming that the boolean expression is easy for you to understand, but
you don't actually know what it does - in fact both your and Arno's
versions are wrong:

  return statement1 && statement2 && statement3 && statement4

is not equivalent to either of the above, it is equivalent to:

  if (!(temp = statement1)) return temp
  if (!(temp = statement2)) return temp
  if (!(temp = statement3)) return temp
  return statement4

[toc] | [prev] | [next] | [standalone]

#39989

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> On 2021-04-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Arno Welzel <usenet@arnowelzel.de> writes:
>>> But this is something one needs to know besides the fact that "&&" means
>>> "logical and" and "||" means "logical or". Therefore I call i at least
>>> bad style to rely on this fact and create code like
>>
>> OK, I see what you mean.  I disagree, but I'm not sure that it matters
>> enough to say much about it.  Bottom line: programmer should know the
>> language, and the language does guarantee what you think of as a
>> convention.
>>
>>> return
>>>   statement1 &&
>>>   statement2 &&
>>>   statement3 &&
>>>   statement4;
>>
>> (Odd terminology.  These have to expressions, not statements.)
>>
>>> instead of
>>>
>>> if (!statement1) {
>>>   return false;
>>> }
>>> if (!statement2) {
>>>   return false;
>>> }
>>> if (!statement3) {
>>>   return false;
>>> }
>>> return statement 4;
>>>
>>> Yes, the latter one needs more lines but is obvious what the code does
>>> even if you don't remember that "&&" is evaluated from left to right and
>>> that the the evaluation stops at the first statement which returns
>>> false.
>>
>> Need three more lines:
>>
>>   if (!statement1) {
>>     return false;
>>   }
>>   if (!statement2) {
>>     return false;
>>   }
>>   if (!statement3) {
>>     return false;
>>   }
>>   if (!statement4) {
>>     return false;
>>   }
>>   return true;
>>
>> You could write return !!statement4; or return statement4 == true; but I
>> assume you'd rather keep the pattern going.
>
> You're kinda disproving your own point here though, since you're the one
> claiming that the boolean expression is easy for you to understand, but
> you don't actually know what it does - in fact both your and Arno's
> versions are wrong:

Touché.  I was forgetting what language this was.  This topic comes up
every year or so in comp.lang.c.

But I don't think I'm making your case.  I'm making mine.  Programmers
should learn the language!

>   return statement1 && statement2 && statement3 && statement4
>
> is not equivalent to either of the above, it is equivalent to:
>
>   if (!(temp = statement1)) return temp
>   if (!(temp = statement2)) return temp
>   if (!(temp = statement3)) return temp
>   return statement4

-- 
Ben.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.javascript

csiph-web