Path: csiph.com!.POSTED.204-73-239-109.cust.centrio.cz!not-for-mail From: Cezary Tomczyk Newsgroups: comp.lang.javascript Subject: Re: why the ! operator can be used to determine a string is null? Date: Thu, 10 Aug 2017 09:10:59 +0200 Organization: csiph.com Internet News Service Message-ID: References: <1939054.irdbgypaU6@PointedEars.de> <11859138.uLZWGnKmhe@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 10 Aug 2017 07:10:59 +0000 (UTC) Injection-Info: csiph.com; posting-host="204-73-239-109.cust.centrio.cz:109.239.73.204"; logging-data="60372"; mail-complaints-to="admin@kev009.com" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: <11859138.uLZWGnKmhe@PointedEars.de> Content-Language: en-GB Xref: csiph.com comp.lang.javascript: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: > > ,- > | > | […] > | > | 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? > > > > 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/