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

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

why the ! operator can be used to determine a string is null?

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

Contents

  why the ! operator can be used to determine a string is null? Xue Feng <xf.lotus@yahoo.com> - 2017-08-08 23:43 +0800
    Re: why the ! operator can be used to determine a string is null? Robert Heller <heller@deepsoft.com> - 2017-08-08 11:16 -0500
    Re: why the ! operator can be used to determine a string is null? Jon Ribbens <jon+usenet@unequivocal.eu> - 2017-08-08 17:40 +0000
      Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-08 21:38 -0700
        Re: why the ! operator can be used to determine a string is null? John G Harris <niam@jghnorth.org.uk.invalid> - 2017-08-09 14:51 +0100
      Re: why the ! operator can be used to determine a string is null? Jon Ribbens <jon+usenet@unequivocal.eu> - 2017-08-09 11:01 +0000
        Re: why the ! operator can be used to determine a string is null? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-09 16:17 +0200
          Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-09 16:14 +0100
            Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-09 10:25 -0700
              Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-09 21:04 +0100
                Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-09 13:11 -0700
                  Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-10 00:59 +0100
                    [ANN] Spam filter for Google Groups (was: why the ! operator can be used to determine a string is null?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-10 05:06 +0200
                      Re: [ANN] Spam filter for Google Groups (was: why the ! operator can be used to determine a string is null?) Julio Di Egidio <julio@diegidio.name> - 2017-08-10 01:00 -0700
                        Re: [ANN] Spam filter for Google Groups (was: why the ! operator can be used to determine a string is null?) John G Harris <niam@jghnorth.org.uk.invalid> - 2017-08-10 09:40 +0100
                    Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-10 00:56 -0700
            Re: why the ! operator can be used to determine a string is null? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-09 22:01 +0200
              Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-09 23:35 +0100
                Re: why the ! operator can be used to determine a string is null? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-10 10:05 +0200
                  Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-10 15:08 +0100
                    Re: why the ! operator can be used to determine a string is null? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-10 16:42 +0200
            Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-09 23:56 +0200
              Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-10 01:40 +0100
                Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-10 03:44 +0200
                  Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-10 03:20 +0100
                    Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-10 04:33 +0200
                      Re: why the ! operator can be used to determine a string is null? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-08-10 03:57 +0100
    Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-08 23:20 +0200
      Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-08 21:20 -0700
        Re: why the ! operator can be used to determine a string is null? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-09 09:26 +0200
          Re: why the ! operator can be used to determine a string is null? Julio Di Egidio <julio@diegidio.name> - 2017-08-09 01:31 -0700
          Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-09 11:32 +0200
            Re: why the ! operator can be used to determine a string is null? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-10 09:10 +0200
              Re: why the ! operator can be used to determine a string is null? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-10 14:51 +0200
                Re: why the ! operator can be used to determine a string is null? Tim Streater <timstreater@greenbee.net> - 2017-08-10 15:11 +0100
                Re: why the ! operator can be used to determine a string is null? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-10 18:52 +0200

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

#33761

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 10 Aug 2017 in 
comp.lang.javascript:

> Of course not.  No one has argued otherwise.

Roger, roger.

> All I said was that the
> presence of yet another meaning for the word "null" adds to the
> confusion (for some people).

Zeroing in from an invertebrate point of view: 

<http://bit.ly/2vqgTJx>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#33742

Ben Bacarisse wrote:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> Jon Ribbens <jon+usenet@unequivocal.eu> wrote on 09 Aug 2017 in
>> comp.lang.javascript:
>>> Unfortunately people tend to be very imprecise as to the meaning of
>>> the phrase "null string", and may variously mean either the actual
>>> null value or an empty string.
>>
>> Indeed,
>> a string is NEVER null,
>> because then it is NOT a string.

Correct regarding the `null` value in ECMAScript.
 
> Further complicated by the fact that there is a character called null
> (sometimes Null, Nul or NULL) so a string can "be null" in that it
> contains just that character.

As we are talking about ECMAScript, it is the Unicode character U+0000 NULL 
(to my surprise, not “NUL” as in US-ASCII) whose standard representation is 
a boxed “NUL” (AFAIK, it is *never* called “null”, “Null” or “Nul”):

<http://www.unicode.org/charts/PDF/U0000.pdf>

Otherwise, well spotted.  Different to C strings, for example, ECMAScript 
strings *can* contain that character without being automatically considered 
terminated (as the value is not used as a termination value).

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

#33746

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

> Ben Bacarisse wrote:
<snip>
>> Further complicated by the fact that there is a character called null
>> (sometimes Null, Nul or NULL) so a string can "be null" in that it
>> contains just that character.
>
> As we are talking about ECMAScript, it is the Unicode character U+0000 NULL 
> (to my surprise, not “NUL” as in US-ASCII) whose standard representation is 
> a boxed “NUL” (AFAIK, it is *never* called “null”, “Null” or “Nul”):

If you can find an original copy of the standard you'll see a table of
control characters that gives "Abbreviations" (though most are acronyms)
and, as you say, NUL is the abbreviation for the first one.  After that
table is an explanation that gives the name as "Null" and the
abbreviation as "Nul" (for some reason not in caps).  Since it's not a
proper name, people write "null" for it just as they write "bell" for
the character abbreviated as in the table as BEL.

<snip>
-- 
Ben.

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

#33747

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
> <snip>
>>> Further complicated by the fact that there is a character called null
>>> (sometimes Null, Nul or NULL) so a string can "be null" in that it
>>> contains just that character.
>> As we are talking about ECMAScript, it is the Unicode character U+0000
>> NULL (to my surprise, not “NUL” as in US-ASCII) whose standard
>> representation is a boxed “NUL” (AFAIK, it is *never* called “null”,
>> “Null” or “Nul”):
> 
> If you can find an original copy of the standard you'll see a table of
> control characters that gives "Abbreviations" (though most are acronyms)
> and, as you say, NUL is the abbreviation for the first one.  After that
> table is an explanation that gives the name as "Null" and the
> abbreviation as "Nul" (for some reason not in caps).

*I have just cited* “an original copy of the standard”, so please cite 
evidence supporting your claims.

> Since it's not a proper name, people write "null" for it just as they
                                ^^^^^^^^^^^^
> write "bell" for the character abbreviated as in the table as BEL.

Weasel wording.  People who do not know what they are talking about are 
irrelevant when one is faced with deciding the correctness of an answer
to a question.

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

#33749

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

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>> <snip>
>>>> Further complicated by the fact that there is a character called null
>>>> (sometimes Null, Nul or NULL) so a string can "be null" in that it
>>>> contains just that character.
>>> As we are talking about ECMAScript, it is the Unicode character U+0000
>>> NULL (to my surprise, not “NUL” as in US-ASCII) whose standard
>>> representation is a boxed “NUL” (AFAIK, it is *never* called “null”,
>>> “Null” or “Nul”):
>> 
>> If you can find an original copy of the standard you'll see a table of
>> control characters that gives "Abbreviations" (though most are acronyms)
>> and, as you say, NUL is the abbreviation for the first one.  After that
>> table is an explanation that gives the name as "Null" and the
>> abbreviation as "Nul" (for some reason not in caps).
>
> *I have just cited* “an original copy of the standard”, so please cite 
> evidence supporting your claims.

X3.4-1967 "The American Standard for Information Interchange".  You may
have to go to a physical library to find it.  I can cite an online scan
of an article from the November 1967 Western Union Technical Review
explaining this new code, but obviously you will need to see the
original.

>> Since it's not a proper name, people write "null" for it just as they
>                                 ^^^^^^^^^^^^
>> write "bell" for the character abbreviated as in the table as BEL.
>
> Weasel wording.  People who do not know what they are talking about are 
> irrelevant when one is faced with deciding the correctness of an answer
> to a question.

The issue is what people write and the confusion it causes.  At no point
have I said any of this is or is not "correct".  The meaning of the
phrase "null string" is confused precisely by people using words
incorrectly or, at best, ambiguously.

-- 
Ben.

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

#33750

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>> <snip>
>>>>> Further complicated by the fact that there is a character called null
>>>>> (sometimes Null, Nul or NULL) so a string can "be null" in that it
>>>>> contains just that character.
>>>> As we are talking about ECMAScript, it is the Unicode character U+0000
>>>> NULL (to my surprise, not “NUL” as in US-ASCII) whose standard
>>>> representation is a boxed “NUL” (AFAIK, it is *never* called “null”,
>>>> “Null” or “Nul”):
>>> If you can find an original copy of the standard you'll see a table of
>>> control characters that gives "Abbreviations" (though most are acronyms)
>>> and, as you say, NUL is the abbreviation for the first one.  After that
>>> table is an explanation that gives the name as "Null" and the
>>> abbreviation as "Nul" (for some reason not in caps).
>> *I have just cited* “an original copy of the standard”, so please cite
>> evidence supporting your claims.
> 
> X3.4-1967 "The American Standard for Information Interchange". 

We are not talking about *that* standard as that has nothing to do with 
ECMAScript; we are talking about the *Unicode* character, therefore the 
corresponding *Unicode* Standard.

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

#33751

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

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>> Ben Bacarisse wrote:
>>>> <snip>
>>>>>> Further complicated by the fact that there is a character called null
>>>>>> (sometimes Null, Nul or NULL) so a string can "be null" in that it
>>>>>> contains just that character.
>>>>> As we are talking about ECMAScript, it is the Unicode character U+0000
>>>>> NULL (to my surprise, not “NUL” as in US-ASCII) whose standard
>>>>> representation is a boxed “NUL” (AFAIK, it is *never* called “null”,
>>>>> “Null” or “Nul”):
>>>> If you can find an original copy of the standard you'll see a table of
>>>> control characters that gives "Abbreviations" (though most are acronyms)
>>>> and, as you say, NUL is the abbreviation for the first one.  After that
>>>> table is an explanation that gives the name as "Null" and the
>>>> abbreviation as "Nul" (for some reason not in caps).
>>> *I have just cited* “an original copy of the standard”, so please cite
>>> evidence supporting your claims.
>> 
>> X3.4-1967 "The American Standard for Information Interchange". 
>
> We are not talking about *that* standard as that has nothing to do with 
> ECMAScript; we are talking about the *Unicode* character, therefore the 
> corresponding *Unicode* Standard.

I was.  The character called NULL in Unicode has a long history.  That
includes begin called NULL and Null in the X3.4-1963 table, NUL, Nul and
Null in the X3.4-1967, NUL, Nul and Null in the first ISO 646 version
(essentially X3.4-1967 re-badged), NUL and Null in RFC 20 (1969) and so
on and so on.  This long history is what causes the confusion which was
my only (rather minor) point.

And you were (talking about US-ASCII) too.  You said it is called NUL in
US-ASCII, but that is only the abbreviated name.  To see what the
character's name really is you must look at some reference document for
ASCII.

-- 
Ben.

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

#33720

Xue Feng wrote:

>     I got an idea by a book that the code can be written as following:
> var ans = prompt("Enter a number: ");
> if (!ans)
> throw ...
> to check whether the 'ans' get a null.
>     I don't understand why the ! operator can do this. thanks.

First of all, it is a misconception or at least misleading to think or say 
“a string is null”.  Proper terminology and proper use of terminology is 
important.  ECMAScript implementations are not like C: strings are _not_ 
pointers to character arrays (NULL in C is equivalent to a null pointer 
value), but they are primitive values.  A String value that contains no 
characters has the _length zero_; it can only be said to be _empty_, and it 
is of the String type.  “null”, by contrast, is a special primitive value, 
of the Null type:

<http://www.ecma-international.org/ecma-262/7.0/#sec-ecmascript-data-types-and-values>

Second, the function call `prompt()` is actually the method call 
`window.prompt()` and should always be written so.  It is only that the 
*host* object referred to by `window` is in the scope chain of almost any 
*Web browser* execution context.

Third, two cases must be distinguished here: One, when the user cancels the 
prompt dialog, and the method returns the “null” value.  Two, when the user 
does not enter a value, confirms the prompt dialog, and the method returns 
the empty string.

<https://developer.mozilla.org/en-US/docs/Web/API/Window/prompt> p.

The conditional works in both cases because the `!` operator is defined this 
way:

  !null === true

  !"" === true

<http://www.ecma-international.org/ecma-262/7.0/#sec-logical-not-operator>

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

#33721

On Tuesday, August 8, 2017 at 11:20:26 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
> Xue Feng wrote:
> 
> >     I got an idea by a book that the code can be written as following:
> > var ans = prompt("Enter a number: ");
> > if (!ans)
> > throw ...
> > to check whether the 'ans' get a null.
> >     I don't understand why the ! operator can do this. thanks.
> 
> First of all, it is a misconception or at least misleading to think or say 

Your post is right on the whole line, thank you for a bit sanity here.

Though, for the chronicle, that and most questions here once upon a time
would have just received a RTFM... which is also important to mention.

> Second, the function call `prompt()` is actually the method call 
> `window.prompt()` and should always be written so.

Nah, that's just a bit of your misplaced dogmatism.

Julio

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

#33723

On 09/08/2017 06:20, Julio Di Egidio wrote:
> On Tuesday, August 8, 2017 at 11:20:26 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
[...]
>> Second, the function call `prompt()` is actually the method call
>> `window.prompt()` and should always be written so.
> 
> Nah, that's just a bit of your misplaced dogmatism.

That's not dogmatism, but a practical and good advice to use full 
reference to a method. Time ago I wrote article about that:

http://www.ctomczyk.pl/js-tip-always-use-full-reference/282/

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#33724

On Wednesday, August 9, 2017 at 9:26:34 AM UTC+2, Cezary Tomczyk wrote:
> On 09/08/2017 06:20, Julio Di Egidio wrote:
> > On Tuesday, August 8, 2017 at 11:20:26 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
> [...]
> >> Second, the function call `prompt()` is actually the method call
> >> `window.prompt()` and should always be written so.
> > 
> > Nah, that's just a bit of your misplaced dogmatism.
> 
> That's not dogmatism, but a practical and good advice to use full 
> reference to a method.

Not any method, rather a property of the global object.  Then I beg to
disagree with both of you, indeed that's an instance of when what matters
is to be consistent, and that's all.

Julio

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

#33725

Cezary Tomczyk wrote:

> On 09/08/2017 06:20, Julio Di Egidio wrote:
>> On Tuesday, August 8, 2017 at 11:20:26 PM UTC+2, Thomas 'PointedEars'
>> Lahn wrote:
>>> Second, the function call `prompt()` is actually the method call
>>> `window.prompt()` and should always be written so.
>> Nah, that's just a bit of your misplaced dogmatism.
> 
> That's not dogmatism, but a practical and good advice to use full
> reference to a method. Time ago I wrote article about that:
> 
> http://www.ctomczyk.pl/js-tip-always-use-full-reference/282/

Your solution to the problem looks suboptimal to me, though.  First you say

| // "global" represent "window" object in browsers

which, AISB, for

  (function (global) {
    /* … */
  }(this));

is questionable.  The ECMAScript 2016 Language Specification, clarifying 
previous Editions, only says in that regard:

,-<http://www.ecma-international.org/ecma-262/7.0/>
| 
| […]
| 
| 4.1 Web Scripting
| 
| A web browser provides an ECMAScript host environment for client-side 
| computation including, for instance, objects that represent windows, 
| menus, pop-ups, dialog boxes, text areas, anchors, frames, history, 
| cookies, and input/output. Further, the host environment provides a means 
| to attach scripting code to events such as change of focus, page and image 
| loading, unloading, error and abort, selection, form submission, and mouse 
| actions. Scripting code appears within the HTML and the displayed page is 
| a combination of user interface elements and fixed and computed text and 
| images. The scripting code is reactive to user interaction and there is no 
| need for a main program.
| 
| A web server provides a different host environment for server-side 
| computation including objects representing requests, clients, and files; 
| and mechanisms to lock and share data. By using browser-side and server-
| side scripting together, it is possible to distribute computation between 
| the client and server while providing a customized user interface for a 
| Web-based application.
| 
| Each Web browser and server that supports ECMAScript supplies its own host 
| environment, completing the ECMAScript execution environment.

and

| 18 The Global Object
| 
| […]
| In addition to the properties defined in this specification the global 
| object may have additional host defined properties. This may include a 
| property whose value is the global object itself; for example, in the HTML 
                                                    ^^^^^^^^^^^
| document object model the `window` property of the global object is the 
| global object itself.

The caveat here is that the first quoted section, being part of section
“4 Overview”, which is not normative, and examples in general, are *not 
normative*.  *Many people misunderstand this* when referring to technical 
specifications, and ECMAScript in particular.

The *ECMAScript Language* Specification does _not_ specify the features of 
the “HTML document object model”; the _“HTML document object model” 
specification_, whatever that is and applies to a runtime environment, does 
(currently, it would be the HTML 5.1 DOM interfaces, and DOM4, for recent 
versions of Web browsers).

But that aside, if one accepts your premise, then you are using

|         if (typeof global.self.close === 'function') {
|             global.self.close();
|         }

1. (AISB,) close() is a *host* object’s method.  You cannot be certain
   that the result of the `typeof` operation is "function" *everywhere*
   if that method can be called.  Therefore, some of us have devised
   isHostMethod() implementations, like jsx.object.isHostMethod().

2. The method has been supported on window objects since
   the beginning (Netscape Navigator 2.0).  Why feature-test it
   *in the same window* to begin with?

   <http://e-pla.net/documents/manuals/javascript-1.0/ref_a-c.html#close_window_method>

3. Why not simply

     window.close();

   ?

   Or, if that looks too uncertain, why not 

     (function (global, window) {
       // … window …
     }(this, this.window));

or

     (function (global) {
       // … global.window …
     }(this));

   ?

   The more error-prone `global.self` indirection, at any rate, appears to 
   be unnecessary.

As for the formatting of the article, I suggest that you do not let code 
lines to be word-wrapped (for me, there are code lines in your article that 
contain only one character from the previous original line).  Not using 
`word-wrap`, and using `overflow-x: auto` instead, enables that; a small 
`padding-right` value should preserve the aesthetics, considering the 
background color.

Alternatively, you should use `/* … */` for documentation comments (my 
standing code style recommendation; however, in this case, then other code 
lines could still be wrapped in unforeseen ways).

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

#33753

On 09/08/2017 11:32, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 09/08/2017 06:20, Julio Di Egidio wrote:
>>> On Tuesday, August 8, 2017 at 11:20:26 PM UTC+2, Thomas 'PointedEars'
>>> Lahn wrote:
>>>> Second, the function call `prompt()` is actually the method call
>>>> `window.prompt()` and should always be written so.
>>> Nah, that's just a bit of your misplaced dogmatism.
>>
>> That's not dogmatism, but a practical and good advice to use full
>> reference to a method. Time ago I wrote article about that:
>>
>> http://www.ctomczyk.pl/js-tip-always-use-full-reference/282/
> 
> Your solution to the problem looks suboptimal to me, though.  First you say
> 
> | // "global" represent "window" object in browsers
> 
> which, AISB, for
> 
>    (function (global) {
>      /* … */
>    }(this));
> 
> is questionable.  The ECMAScript 2016 Language Specification, clarifying
> previous Editions, only says in that regard:
> 
> ,-<http://www.ecma-international.org/ecma-262/7.0/>
> |
> | […]
> |
> | 4.1 Web Scripting
> |
> | A web browser provides an ECMAScript host environment for client-side
> | computation including, for instance, objects that represent windows,
> | menus, pop-ups, dialog boxes, text areas, anchors, frames, history,
> | cookies, and input/output. Further, the host environment provides a means
> | to attach scripting code to events such as change of focus, page and image
> | loading, unloading, error and abort, selection, form submission, and mouse
> | actions. Scripting code appears within the HTML and the displayed page is
> | a combination of user interface elements and fixed and computed text and
> | images. The scripting code is reactive to user interaction and there is no
> | need for a main program.
> |
> | A web server provides a different host environment for server-side
> | computation including objects representing requests, clients, and files;
> | and mechanisms to lock and share data. By using browser-side and server-
> | side scripting together, it is possible to distribute computation between
> | the client and server while providing a customized user interface for a
> | Web-based application.
> |
> | Each Web browser and server that supports ECMAScript supplies its own host
> | environment, completing the ECMAScript execution environment.
> 
> and
> 
> | 18 The Global Object
> |
> | […]
> | In addition to the properties defined in this specification the global
> | object may have additional host defined properties. This may include a
> | property whose value is the global object itself; for example, in the HTML
>                                                      ^^^^^^^^^^^
> | document object model the `window` property of the global object is the
> | global object itself.
> 
> The caveat here is that the first quoted section, being part of section
> “4 Overview”, which is not normative, and examples in general, are *not
> normative*.  *Many people misunderstand this* when referring to technical
> specifications, and ECMAScript in particular.
> 
> The *ECMAScript Language* Specification does _not_ specify the features of
> the “HTML document object model”; the _“HTML document object model”
> specification_, whatever that is and applies to a runtime environment, does
> (currently, it would be the HTML 5.1 DOM interfaces, and DOM4, for recent
> versions of Web browsers).

My understanding was based on:

>> | document object model the `window` property of the global object is the
>> | global object itself.

That's why I was using:

(function(global){

}(this));

because this in above will always point to the window object.

https://developer.mozilla.org/en-US/docs/Glossary/Global_object

"In a web browser, any code which the script doesn't specifically start 
up as a background task has a Window as its global object. This is the 
vast majority of JavaScript code on the Web."

> But that aside, if one accepts your premise, then you are using
> 
> |         if (typeof global.self.close === 'function') {
> |             global.self.close();
> |         }
> 
> 1. (AISB,) close() is a *host* object’s method.  You cannot be certain
>     that the result of the `typeof` operation is "function" *everywhere*
>     if that method can be called.  Therefore, some of us have devised
>     isHostMethod() implementations, like jsx.object.isHostMethod().

Fair enough.

> 2. The method has been supported on window objects since
>     the beginning (Netscape Navigator 2.0).  Why feature-test it
>     *in the same window* to begin with?
> 
>     <http://e-pla.net/documents/manuals/javascript-1.0/ref_a-c.html#close_window_method>
> 
> 3. Why not simply
> 
>       window.close();
> 
>     ?

Why not. Some of the methods exists since the beginning.
How do you decide when not to use isHostMethod?

>     Or, if that looks too uncertain, why not

>       (function (global, window) {
>         // … window …
>       }(this, this.window));
> or
> 
>       (function (global) {
>         // … global.window …
>       }(this));
> 
>     ?
Both looks good.

>     The more error-prone `global.self` indirection, at any rate, appears to
>     be unnecessary.
> 
> As for the formatting of the article, I suggest that you do not let code
> lines to be word-wrapped (for me, there are code lines in your article that
> contain only one character from the previous original line).  Not using
> `word-wrap`, and using `overflow-x: auto` instead, enables that; a small
> `padding-right` value should preserve the aesthetics, considering the
> background color.
> 
> Alternatively, you should use `/* … */` for documentation comments (my
> standing code style recommendation; however, in this case, then other code
> lines could still be wrapped in unforeseen ways).

I've removed `word-wrap` and added `overflow-x: auto`. It should looks 
better now.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#33758

Cezary Tomczyk wrote:

> On 09/08/2017 11:32, Thomas 'PointedEars' Lahn wrote:
>> The caveat here is that the first quoted section, being part of
>> section “4 Overview”, which is not normative, and examples in general,
>> are *not normative*.  *Many people misunderstand this* when referring
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> to technical specifications, and ECMAScript in particular.
>> 
>> The *ECMAScript Language* Specification does _not_ specify the
>> features of the “HTML document object model”; the _“HTML document
>> object model” specification_, whatever that is and applies to a runtime
>> environment, does (currently, it would be the HTML 5.1 DOM interfaces,
>> and DOM4, for recent versions of Web browsers).
> 
> My understanding was based on:
> 
>>> | document object model the `window` property of the global object
>>> is | the global object itself.

Yes, I figured.

> That's why I was using:
> 
> (function(global){
> 
> }(this));
> 
> because this in above will always point to the window object.
> 
> https://developer.mozilla.org/en-US/docs/Glossary/Global_object
> 
> "In a web browser, any code which the script doesn't specifically start 
> up as a background task has a Window as its global object. This is the 
> vast majority of JavaScript code on the Web."

Never accept claims at face value.

>> 2. The method has been supported on window objects since the beginning
>>  (Netscape Navigator 2.0).  Why feature-test it *in the same window* to
>>  begin with?
>> 
>> <http://e-pla.net/documents/manuals/javascript-1.0/ref_a-c.html#close_window_method>
>>
>>  3. Why not simply
>> 
>> window.close();
>> 
>> ?
> 
> Why not. Some of the methods exists since the beginning. How do you 
> decide when not to use isHostMethod?

As a rule of thumb, if the object in question always had the method and it
always worked, I do not feature-test it.  Probably I have not been
consistent regarding this as I do not have a suitable DOM Support Matrix
yet, and am checking that on a case-by-case basis.

>> As for the formatting of the article, I suggest that you do not let 
>> code lines to be word-wrapped (for me, there are code lines in your 
>> article that contain only one character from the previous original 
>> line).  Not using `word-wrap`, and using `overflow-x: auto` instead, 
>> enables that; a small `padding-right` value should preserve the 
>> aesthetics, considering the background color.
>> […]
> 
> I've removed `word-wrap` and added `overflow-x: auto`. It should looks 
> better now.

ACK, it does.  Maybe if you use less characters per line (e.g., reduce the
indentation two two spaces) or use a slightly smaller font-size, it looks
even better :)

Please trim your quotes to the relevant minimum next time.

.
.
.
.
.
.

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

#33760

In article <e9b36921-388f-976d-2d08-ea3cc91e66ec@PointedEars.de>,
Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

>ACK, it does.  Maybe if you use less characters per line (e.g., reduce the

Tsk, tsk:  "fewer characters"

"less" is used for something uncountable, such as water or sand.

"fewer" is used for something countable, such as people.

-- 
Labour - a bunch of rich people convincing poor people to vote for rich people
by telling poor people that "other" rich people are the reason they are poor.

Peter Thompson

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

#33762

On 10/08/2017 14:51, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
[...]

>> https://developer.mozilla.org/en-US/docs/Glossary/Global_object
>>
>> "In a web browser, any code which the script doesn't specifically start
>> up as a background task has a Window as its global object. This is the
>> vast majority of JavaScript code on the Web."
> 
> Never accept claims at face value.

I know ;-) Better to check in several, independent places to compare 
results.

>> [...] How do you decide when not to use isHostMethod?
> 
> As a rule of thumb, if the object in question always had the method and it
> always worked, I do not feature-test it.  Probably I have not been
> consistent regarding this as I do not have a suitable DOM Support Matrix
> yet, and am checking that on a case-by-case basis.

Make sense. I shouldn't be so strict in checking for something that 
exists for long time.

[...]
>> I've removed `word-wrap` and added `overflow-x: auto`. It should looks
>> better now.
> 
> ACK, it does.  Maybe if you use less characters per line (e.g., reduce the
> indentation two two spaces) or use a slightly smaller font-size, it looks
> even better :)

I've reduced a little font-size. :-)

> Please trim your quotes to the relevant minimum next time.

Done.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [standalone]

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

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

csiph-web