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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#39992

On 2021-04-20, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>> You do of course have a point about following the spec, but to my mind
>> (and we're deviating considerably from the original topic here) it just
>> shows how this sort of "specification" is an absolute abomination. Many
>> of the modern web specifications are similar. They don't tell you what
>> things mean, they just give random algorithms and you have to work out
>> the meaning for yourself. They're basically the opposite of a
>> specification. I had to reverse-engineer the CSSOM spec in order to find
>> out what it actually meant, in order to write my implementation. If it
>> was an actual specification, what I just said would be nonsensical.
>
> I think concentrating on the term "specification" is slightly
> distracting up from the big picture.  I was trying to say that
> readability is much deeper than the meaning of the surface syntax.
> After all, that can be looked up, but how clearly the code represents
> the method used to get the desired result is often the hard part of what
> we mean by "readability".

My version 1 closely matches what I think a proper spec should look like
- i.e. it is clear what it *means*. Your version (and to a lesser extent
my version 2) matches the actual spec - which substitutes a particular
implementation for meaning. If it wasn't for the spec being terrible,
the only reason to prefer your version or my version 2 would be
performance.

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

#39971

Ben Bacarisse:

> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
[...]
>> It's not a rule of mine, it seems to be a rule of almost everyone.
> 
> The trouble is that a non-trivial number of languages have this form,

Yes - but this is more a side effect than a intended way to use those
languages.

[...]
> I've seen (and, dare I say, written) code that uses the result.  I
> wonder if that absolves the programmer from the charge of abuse:
> 
>   return (data = parse_input(file_name))
>       && (result = transform(data))
>       && write_file(file_name);

In a polite way I'd say this is the result of someone who is really lazy
and want's to avoid typing as much as possible. That's ok if you do a
project just for yourself. But as soon as you need to work in a team,
readibility *is* more important than having the shortest possible code.


-- 
Arno Welzel
https://arnowelzel.de

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

#39976

Arno Welzel <usenet@arnowelzel.de> writes:

> Ben Bacarisse:
>
>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
> [...]
>>> It's not a rule of mine, it seems to be a rule of almost everyone.
>> 
>> The trouble is that a non-trivial number of languages have this form,
>
> Yes - but this is more a side effect than a intended way to use those
> languages.

I think that's likely in most cases, but Perl added 'and' and 'or' with
the same semantic as it's existing && and || but with much lower
precedence so that they could be used for this kind of thing more
easily.

> [...]
>> I've seen (and, dare I say, written) code that uses the result.  I
>> wonder if that absolves the programmer from the charge of abuse:
>> 
>>   return (data = parse_input(file_name))
>>       && (result = transform(data))
>>       && write_file(file_name);
>
> In a polite way I'd say this is the result of someone who is really lazy
> and want's to avoid typing as much as possible. That's ok if you do a
> project just for yourself. But as soon as you need to work in a team,
> readibility *is* more important than having the shortest possible
> code.

I never aim to the shortest code, but readability is not an absolute.
Who is doing the reading?  Do we assume, for the purposes of assessing
readability, the very lowest absolute minimum understanding?  I don't
think I've worked with any colleagues who would have the slightest
trouble reading that statement.  I fully admit that my experience is
probably atypical, but some people just work in an environment with
different notions of what is hard to read.

By the way, I'm not suggesting that there could not be other good
reasons to re-write such things, just that there may be environments in
which its readability would not come up as an issue.

-- 
Ben.

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

#39961

Ben Bacarisse wrote:

> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>> On 2021-04-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>> You most often see this sort of thing in JavaScript that was
>>>> automatically generated by a compiler (either because the original
>>>> source was in something else like TypeScript or a more modern version
>>>> of JavaScript or because the author wanted to compress/minify the
>>>> script), but human beings are also quite capable of writing
>>>> hard-to-read code like this.
>>>
>>> Is that specifically when the right-hand operand is an assignment
>>> expression?  I don't find that hard to read but then I'm used to
>>> assignment being and expression so it seems like a natural extension of
>>> the more frequently seen uses of &&.
>>
>> I mean where it's an expression being abused as a control flow
>> mechanism.
> 
> If readability is not the problem I'm not sure what constitutes abuse.

To begin with: One is a *statement*, the other an *expression*.  Those are 
two different kinds of token in a programming language (certainly in 
ECMAScript implementations).

Also, such code easily makes newcomers think that

  a && b || c

would be equivalent to

  if (a) b; else c;

but it is NOT: In the former case, if “a” evaluates to a false-value, then 
“c” is evaluated; but if “a” evaluates to a true-value, then “b” is 
evaluated, and “c” is *also* evaluated afterwards if “b” evaluates to a 
false-value.  Whereas with in the latter case, “c” is never evaluated if “a” 
is evaluates to a true-value.

A special case is that “b” is an assignment expression in the literal sense.  
Perhaps counter-intuitively, the result of such an expression is NOT the 
evaluated left-hand side *after* assignment but the evaluated *right-hand* 
side *before* assignment.  This is important to realize, for example, if the 
left-hand side refers to a property as that may be read-only or have a 
setter:

Suppose that “o” refers to an object that has a property named “p”, then the 
"shortcut"

  let success = (o.p = 42) === 42;

will always assign “true” to “success”, even if o.p does not actually have 
the value "42" afterwards (i.e. the assignment was NOT successful), and the 
"shortcut"

  (o.p = 42) === 42 && doSomething();

will *always* call doSomething().

Patterns like

  var x = x || defaultValue;

instead of

  if (!x) var x = defaultValue;

are equally problematic.

[Notably,

  let x = x || defaultValue;

is not equivalent to

  if (!x) let x = defaultValue;

Both are actually *invalid* code (even if “defaultValue” is declared), but 
the first one produces a ReferenceError (“x is not defined“) while the 
second one produces a SyntaxError (“Lexical declaration cannot appear in a 
single-statement context”).]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#39967

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>> On 2021-04-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>>> You most often see this sort of thing in JavaScript that was
>>>>> automatically generated by a compiler (either because the original
>>>>> source was in something else like TypeScript or a more modern version
>>>>> of JavaScript or because the author wanted to compress/minify the
>>>>> script), but human beings are also quite capable of writing
>>>>> hard-to-read code like this.
>>>>
>>>> Is that specifically when the right-hand operand is an assignment
>>>> expression?  I don't find that hard to read but then I'm used to
>>>> assignment being and expression so it seems like a natural extension of
>>>> the more frequently seen uses of &&.
>>>
>>> I mean where it's an expression being abused as a control flow
>>> mechanism.
>> 
>> If readability is not the problem I'm not sure what constitutes abuse.
>
> To begin with: One is a *statement*, the other an *expression*.

It's not clear what you are referring to.  There have been both
expressions and statements posted, so we could just pick some examples
and assume that's what you are referring to, but it's an odd remark to
begin with.  No one in the discussion is a beginner.

> Those are 
> two different kinds of token in a programming language (certainly in 
> ECMAScript implementations).

Neither is a token in ECMAScript.

> Also, such code easily makes newcomers think that
>
>   a && b || c
>
> would be equivalent to
>
>   if (a) b; else c;

I don't think there's much you can do for people like that.  These two
are so obviously not equivalent that someone who might think they are
can't be helped by banning or deprecating certain uses.  Even the newest
newcomer should know the difference between an expression and a
statement.

-- 
Ben.

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

#39970

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>> I mean where it's an expression being abused as a control flow
>>>> mechanism.
>>> If readability is not the problem I'm not sure what constitutes abuse.
>> To begin with: One is a *statement*, the other an *expression*.
> 
> It's not clear what you are referring to.

I was, of course, referring to the “if” *statement* and the boolean 
*expression*.

> There have been both expressions and statements posted, so we could just
> pick some examples and assume that's what you are referring to, but it's
> an odd remark to begin with.  No one in the discussion is a beginner.

I cannot help you in a textual medium if you have a basic "reading problem".

> [tl;dr]
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#39975

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>>> I mean where it's an expression being abused as a control flow
>>>>> mechanism.
>>>> If readability is not the problem I'm not sure what constitutes abuse.
>>> To begin with: One is a *statement*, the other an *expression*.
>> 
>> It's not clear what you are referring to.
>
> I was, of course, referring to the “if” *statement* and the boolean 
> *expression*.
>
>> There have been both expressions and statements posted, so we could just
>> pick some examples and assume that's what you are referring to, but it's
>> an odd remark to begin with.  No one in the discussion is a beginner.
>
> I cannot help you in a textual medium if you have a basic "reading
> problem".

So you were just making a correct remark that had nothing to with the
material quoted?

>> [tl;dr]

And I'm the one with the basic "reading problem"?

-- 
Ben.

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

#39985

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>>>> I mean where it's an expression being abused as a control flow
>>>>>> mechanism.
>>>>> If readability is not the problem I'm not sure what constitutes abuse.
>>>> To begin with: One is a *statement*, the other an *expression*.
>>> It's not clear what you are referring to.
>> I was, of course, referring to the “if” *statement* and the boolean
>> *expression*.
>>
>>> There have been both expressions and statements posted, so we could just
>>> pick some examples and assume that's what you are referring to, but it's
>>> an odd remark to begin with.  No one in the discussion is a beginner.
>>
>> I cannot help you in a textual medium if you have a basic "reading
>> problem".
> 
> So you were just making a correct remark that had nothing to with the
> material quoted?

I tried (and obviously failed) to connect the dots for you.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#39978

On Sat, 17 Apr 2021 17:05:11 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>To begin with: One is a *statement*, the other an *expression*.
  <snip>

To be exact,

  delta[0] && (target.style.width = `${width}px`);

is a *statement*, of the kind called expression statement.

  John

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

#39968

Ben Bacarisse:

> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
> 
>> On 2021-04-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>> You most often see this sort of thing in JavaScript that was
>>>> automatically generated by a compiler (either because the original
>>>> source was in something else like TypeScript or a more modern version
>>>> of JavaScript or because the author wanted to compress/minify the
>>>> script), but human beings are also quite capable of writing hard-to-read
>>>> code like this.
>>>
>>> Is that specifically when the right-hand operand is an assignment
>>> expression?  I don't find that hard to read but then I'm used to
>>> assignment being and expression so it seems like a natural extension of
>>> the more frequently seen uses of &&.
>>
>> I mean where it's an expression being abused as a control flow
>> mechanism.
> 
> If readability is not the problem I'm not sure what constitutes abuse.

Abuse is to use things for something which they are not meant to be
used. An *expression* is called so because you *express* something like

x = a && b;

Nobody would expect that this *expression* will cause parts of the code
to get executed or not like in this example:

x = a && (b=5);

It's not just a "readability problem". It's relying on side effects like
that in a && b the "b" part will not get exectued if "a" is false. But
this is just a convention and nothing obvious.

> Is it just a rule of yours to keep these two things entirely separate?
> Maybe some uses are acceptable and don't constitute abuse?  Is any

I see this as "abuse" as well.

> reliance on short-circuit evaluation in an expression an abuse?  If so,
> does that extend to '??' and '?.'?  (That's not easy to make clear in
> typing but I hope you know what I mean.)

The ??= operator was *intentionally* designed to work this way.

x ??= y;

will assign y to x only if x is not null or undefined. There is no
surprise here what to expect from this expression.

However:

x = a && (b=5);

Will assing something to x and *maybe* to b as well if a is not false.

To understand this you need not only to know what the operator && does
but also that it is evaluated from left to right and that if the left
part is false the right part won't be used at all.

> I only suggested that assignment might be where it crosses the line for
> you because I think that's where the line is for a lot of people, but it
> sounds like go further than that.
> 
> I go the other way.  Statements (most of them at least) are just wasted
> expression opportunities.  It's less noticeable in ECMAScript, than in
> many other languages, but it still bugs me every now and then.

Well - if you feel comfortable with this, you can but a whole program
into a a few expressions without barely any statement at all. But this
has nothing to do with good code style or anything which should be
recommended as good practice.


-- 
Arno Welzel
https://arnowelzel.de

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

#39972

Arno Welzel <usenet@arnowelzel.de> writes:

> Ben Bacarisse:
>
>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>> 
>>> On 2021-04-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>>>> You most often see this sort of thing in JavaScript that was
>>>>> automatically generated by a compiler (either because the original
>>>>> source was in something else like TypeScript or a more modern version
>>>>> of JavaScript or because the author wanted to compress/minify the
>>>>> script), but human beings are also quite capable of writing hard-to-read
>>>>> code like this.
>>>>
>>>> Is that specifically when the right-hand operand is an assignment
>>>> expression?  I don't find that hard to read but then I'm used to
>>>> assignment being and expression so it seems like a natural extension of
>>>> the more frequently seen uses of &&.
>>>
>>> I mean where it's an expression being abused as a control flow
>>> mechanism.
>> 
>> If readability is not the problem I'm not sure what constitutes abuse.
>
> Abuse is to use things for something which they are not meant to be
> used. An *expression* is called so because you *express* something
> like

I don't think it's not that simple.  In some views, an expression can
express an action, and a statement can describe actions that express a
value.  Obviously you are in the oil and water camp about this, but the
arguments for that should be more than quasi tautologies about
expressions expressing something.

> 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?

> like in this example:
>
> x = a && (b=5);
>
> It's not just a "readability problem". It's relying on side effects like
> that in a && b the "b" part will not get exectued if "a" is false. But
> this is just a convention and nothing obvious.
>
>
>> Is it just a rule of yours to keep these two things entirely separate?
>> Maybe some uses are acceptable and don't constitute abuse?  Is any
>
> I see this as "abuse" as well.
>
>> reliance on short-circuit evaluation in an expression an abuse?  If so,
>> does that extend to '??' and '?.'?  (That's not easy to make clear in
>> typing but I hope you know what I mean.)
>
> 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.

That aside, I think && and || were intentionally designed to work as
they do, so intentional design can't justification enough in your mind.

-- 
Ben.

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

#39974

On 2021-04-17, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Arno Welzel <usenet@arnowelzel.de> writes:
>> 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.

It's a proposal:

  https://tc39.es/proposal-logical-assignment/

but it's a "stage 4" proposal which basically means it's in the standard
but they just haven't got around to publishing an updated version yet,
and it's supported by Node, Chrome, Edge, Safari, and Firefox...

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

#39977

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

> On 2021-04-17, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Arno Welzel <usenet@arnowelzel.de> writes:
>>> 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.
>
> It's a proposal:
>
>   https://tc39.es/proposal-logical-assignment/

Thanks.  I was rather surprised to find that the three were not already
there.

Since they also added &&= and ||=, the argument that ??= is ok looks
weak.  Arno's "ok" example of ??= applies equally to &&= being
intentionally designed to do what it does, and his example of poor use
of && in an expression could equally have been written using ??.

> but it's a "stage 4" proposal which basically means it's in the standard
> but they just haven't got around to publishing an updated version yet,
> and it's supported by Node, Chrome, Edge, Safari, and Firefox...

I tried to get node to accept it but my version (12.18.2) must be too
old.

-- 
Ben.

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

#39979

On 2021-04-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>> It's a proposal:
>>
>>   https://tc39.es/proposal-logical-assignment/
>
> Thanks.  I was rather surprised to find that the three were not already
> there.
>
> Since they also added &&= and ||=, the argument that ??= is ok looks
> weak.  Arno's "ok" example of ??= applies equally to &&= being
> intentionally designed to do what it does, and his example of poor use
> of && in an expression could equally have been written using ??.
>
>> but it's a "stage 4" proposal which basically means it's in the standard
>> but they just haven't got around to publishing an updated version yet,
>> and it's supported by Node, Chrome, Edge, Safari, and Firefox...
>
> I tried to get node to accept it but my version (12.18.2) must be too
> old.

Yes, I was quite surprised recently when I happened to add a line using
"||=" to a file in a project and inadvertently this turned out to
introduce a requirement of node 15.

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

#39982

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.

[...]
>> 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.

> 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

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

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.


-- 
Arno Welzel
https://arnowelzel.de

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

#39984

On Mon, 19 Apr 2021 13:41:09 +0200, Arno Welzel <usenet@arnowelzel.de>
wrote:

  <snip>
>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.
  <snip>

Actually, it's specified behaviour. See ECMA 262, June 2020, 
section 12.13.3.

  John

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

#39993

On 19/04/2021 15:02, John G Harris wrote:
> On Mon, 19 Apr 2021 13:41:09 +0200, Arno Welzel <usenet@arnowelzel.de>
> wrote:
> 
>    <snip>
>> 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.
>    <snip>
> 
> Actually, it's specified behaviour. See ECMA 262, June 2020,
> section 12.13.3.
> 
>    John
> 
specified behaviour IS convention.



-- 
"When a true genius appears in the world, you may know him by this sign, 
that the dunces are all in confederacy against him."

Jonathan Swift.

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

#39994

On Tue, 20 Apr 2021 17:40:06 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

  <snip>
>specified behaviour IS convention.

You regard specified behaviour to be a proper subset of convention.
What was the point of your comment?

  John

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

#40001

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.
> 
> You regard specified behaviour to be a proper subset of convention.
> What was the point of your comment?
> 
>    John
> 
person as says its a convention
person be says  it's in the specification
I point out that 'specified behaviour' *is* a subset of convention. 
Convention cast in concrete, as it were.



Therefore the remark is superflous

It's not just code that needs to be precise ;-)

-- 
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

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

#40002

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"

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

  John

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

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

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

csiph-web