Mystical incantation of the day

[RobG]

I seem to remember a thread about these things some time ago, anyway
came across a new one:

(function(global) {
...
})(typeof window === 'undefined' ? this : window);

Lots to ponder there.


--
Rob

[Richard Cornford]

I was thinking back to that thread earlier in week when I encountered
this code in an object literal:-

oPlugin = {
...
Browser: {
Explorer:!!(navigator.appName=='Microsoft Internet Explorer'),
Other: !!!(navigator.appName=='Microsoft Internet Explorer'),
Chrome: !!(navigator.userAgent.toLowerCase().indexOf('chrome')>-1)
},
...
}

It is that middle - Other - property definition that really demonstrates
someone doing something with a serious misconception of why they are
doing it.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

> oPlugin = {
> ...
> Browser: {
> Explorer:!!(navigator.appName=='Microsoft Internet Explorer'),
> Other: !!!(navigator.appName=='Microsoft Internet Explorer'),
> Chrome: !!(navigator.userAgent.toLowerCase().indexOf('chrome')>-1)
> },
> ...
> }
>
> It is that middle - Other - property definition that really demonstrates
> someone doing something with a serious misconception of why they are
> doing it.

It is the needless double negation of an intrinsically boolean value in the
`Explorer:' line that shows me the cluelessness of the author already.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Asen Bozhilov]

Obviously this is coded by script kid. In global execution context the
`this` value always refers to a global object. Using of `window` to
get global object here is useless and leads to confusion. If I have to
read that code, when I see formal parameter with name `global' I would
expect its value to be the value of `this` passed during invocation of
that function.

The whole idea for passing arguments to immediately executed function
expression leads readability problems. As a reader to see the actual
value of `global' I have to go to the end of the function. Usually
such functions are used for modules and therefore their body is longer
than my visible part of the monitor. I would have to scroll first to
the bottom and back again to the top.

The whole idea for that design comes from ECMAScript 5 strict-mode and
some premature lookup optimizations. In ECMAScript 5 if the function
code is strict code the `this` value is not coerced to global object,
on entering in the execution context of the function.

So this design is "defensive" and "performance" tuning. The programmer
expects some kid to put "use strict"; on the top of his code and that
would break the program. How this defense is reasonable is really
questionable. In the other hand during the debug stage strict-mode
would be helpful. Instead of passing arguments he can apply different
strategy. Using `call' method of fucntion he can explicitly provide
the value of `this` and therefore its value could be same in string
and non-strict mode.

(function () {
//...
}).call(this);

The `this` value is always bound to the `this` of surrounded execution
context. If the code is placed in global execution context the `this`
value in that function will always be a reference to global object.

[Thomas 'PointedEars' Lahn]

For a more streamlined discussion, what exactly are the issues that you see
with that code?

[insin]

Depends how global is being used in the function body.

You sometimes see this in code which is intended to be shared between
Node.js (or other server-side JS implementations) and browsers, in
which module contents are exported to global instead of whatever
server-side module format is available.

--
Jonny.

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>
>> oPlugin = {
>> ...
>> Browser: {
>> Explorer:!!(navigator.appName=='Microsoft Internet Explorer'),
>> Other: !!!(navigator.appName=='Microsoft Internet Explorer'),
>> Chrome: !!(navigator.userAgent.toLowerCase().indexOf('chrome')>-1)
>> },
>> ...
>> }
>>
>> It is that middle - Other - property definition that really
>> demonstrates someone doing something with a serious misconception
>> of why they are doing it.
>
> It is the needless double negation of an intrinsically boolean value
> in the `Explorer:' line that shows me the cluelessness of the author
> already.

Yes, but that is only a demonstration of someone not understanding when,
where and why it is appropriate to force type-type conversion. The next
line adds not understanding how this type-conversion works, or at least
not stopping to think about it.

Richard.

[Richard Cornford]

insin wrote:

> On Feb 18, 2:40 am, RobG wrote:
>> I seem to remember a thread about these things some time
>> ago, anyway came across a new one:
>>
>> (function(global) {
>> ...
>> })(typeof window === 'undefined' ? this : window);
>>
>> Lots to ponder there.
>

> Depends how global is being used in the function body.
>
> You sometimes see this in code which is intended to be shared
> between Node.js (or other server-side JS implementations) and
> browsers, in which module contents are exported to global
> instead of whatever server-side module format is available.

That may be the rationale for the code but in order for it to be valid
it would be necessary to show circumstances where just passing in the -
this - value as the argument and forgetting about the - window -
reference would make a difference. Because even though Node.js may be
executing in an environment without a - window - reference defined no
ECMAScript can be executing in an environment where the - this -
keyword's value is not fully specified. That is, if it is valid to use
the - this - value anywhere it must be valid for the same code to use it
everywhere.

Richard.

[Richard Cornford]

That would be an explanation of why there is a - global - formal
parameter for the function along with an object argument to the function
call (though, as you say, not necessarily a good (i.e. well justified)
explanation), but it does not justify the attempt to draw the
distinction between the ECMAScript global object and the/a - window -
object when deciding what that argument will be.

Richard.