'undefined' in declaration of function

[trunikov]

Hi All :)

I've taken a look inside the jquery (core) library. I saw there strange function declaration:

(function( window, undefined ) {
// bla bla bla
})();

Tell me please what is a goal to define last parameter as 'undefined'?
How does it work?

Thanks :)

[Scott Sauyet]

trunikov wrote:
> I've taken a look inside the jquery (core) library. I saw there strange function declaration:

First of all, you might see a lot of strange things there! The jQuery
team goes through some interesting gymnastics to reduce code size,
sacrificing readability for brevity. Unless you're already fairly
experienced, I would not suggest the jQuery core as a good model of
how to write your own code. If you are, you might find some
interesting tricks in there. But that said, this is a common idiom,
although I think you misquote it:

> (function( window, undefined ) {
>   // bla bla bla
> })();

I imagine that it actually reads:

| (function( window, undefined ) {
|   // bla bla bla

| })(this);
^^^^

The `this` parameter here is used so that the `window` parameter
inside the function is a reference to the global object. In many
situations, it already is, but this technique enforces that.

> Tell me please what is a goal to define last parameter as 'undefined'?
> How does it work?

One silly flaw in Javascript that would probably have been removed had
the language not been standardized so quickly is that `undefined` is
not a keyword like `null`. It is simply a global property. Arbitrary
code can overwrite it. So a library like jQuery that's operating in a
very heterogeneous environment cannot assume that no other code has
overwritten that property. This is one way to restore it. Inside the
function, `undefined` is now pointing to the value of the second
parameter passed to the function. Since we don't pass a parameter
there, the value is undefined, exactly what we want the `undefined`
property to represent. Note that this does *not* override the global
property; it simply shadows it. Outside this function, everything
reverts to the way it was (except that any functions which close over
`undefined` will also have the shadowing version [and if that doesn't
make any sense to you, don't worry about it for now.])

There are other ways this could be done, but this one is common, and I
don't see any major flaws with it? Other opinions?

-- Scott

[trunikov]

Hi Scott :)
Thank you very much for lucid explanation.
I didn't know heretofore that 'undefined' can be overridden/masked.
And you are absolutely right about error in the code snippet.
It should looks like this:

(function( window, undefined ) {
// bla bla bla

})(window);

[Dr J R Stockton]

In comp.lang.javascript message <617c6390-5eea-43e2-881b-0fb60bb62e46@t3
5g2000yqd.googlegroups.com>, Tue, 29 May 2012 05:30:44, Scott Sauyet
<scott....@gmail.com> posted:

>One silly flaw in Javascript that would probably have been removed had
>the language not been standardized so quickly is that `undefined` is
>not a keyword like `null`. It is simply a global property. Arbitrary
>code can overwrite it. So a library like jQuery that's operating in a
>very heterogeneous environment cannot assume that no other code has
>overwritten that property. This is one way to restore it. Inside the
>function, `undefined` is now pointing to the value of the second
>parameter passed to the function. Since we don't pass a parameter
>there, the value is undefined, exactly what we want the `undefined`
>property to represent. Note that this does *not* override the global
>property; it simply shadows it. Outside this function, everything
>reverts to the way it was (except that any functions which close over
>`undefined` will also have the shadowing version [and if that doesn't
>make any sense to you, don't worry about it for now.])
>
>There are other ways this could be done, but this one is common, and I
>don't see any major flaws with it? Other opinions?

The routine is then relying on something external to itself, its call.

I have used var U within the routine, with U on one side of ==
or != tests, with success; possibly === or !== tests would be
safer; I don't generally use U for any other purpose when confusion
might occur.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Scott Sauyet]

Dr J R Stockton wrote:
> Scott Sauyet wrote:
>> [an explanation of the use of `undefined` in the following]
>>| (function(window, undefined) {
>>| // ...
>>| }(this));

>> There are other ways this could be done, but this one is common, and I
>> don't see any major flaws with it?  Other opinions?
>
> The routine is then relying on something external to itself, its call.

Yes, it should only be used as described, when the function is
immediately executed. But that's not a significant limitation. The
function and its invocation are inextricably bound together in such
blocks of code.

> I have used    var U    within the routine, with U on one side of  ==
> or  !=  tests, with success;  possibly  ===  or  !==  tests would be
> safer;  I don't generally use  U  for any other purpose when confusion
> might occur.

Yes this is another technique, although I usually prefer a variable
name such as `undef`. Another I've seen is to assign it explicitly:

var undef = void 0;

although I don't see that this gains anything over

var undef;

AISB, there are many options.

-- Scott

[lew...@gmail.com]

I was wondering today why undefined has not been made a reserved word even in newer versions of Javascript, and I think that this idiom explains why; much like making "typeof null" return 'null' it turns out that making undefined a reserved word would break code using this idiom.

Although I do like this usage of an unused parameter to enforce the values of undefined and window (it's cleaner than "void 0" and can't be overridden by outside code), I don't like the fact that code inside a function can declare a variable with the name 'undefined' even in strict mode (which makes it impossible to assign a new value to the global undefined, among other improvements). Then again, if you do something like this, you're only hurting yourself, and outside code cannot affect your code in this way, by making new variable assignments in the scope of existing functions.

[Scott Sauyet]

lew...@gmail.com wrote:

> [ ... RE: (function(window, undefined) {/* ... */})(this) ... ]

> I was wondering today why undefined has not been made a reserved
> word even in newer versions of Javascript, and I think that this
> idiom explains why; much like making "typeof null" return 'null'
> it turns out that making undefined a reserved word would break
> code using this idiom.

I don't think it's this idiom at issue any more than the sort of
code that this idiom is designed to prevent. The problem with
adding any new reserved word is that it breaks any existing code
that uses that word in an incompatible fashion.

> [ ... ]

> I don't like the fact that code inside a function can declare a

> variable with the name 'undefined' even in strict mode [ ... ]

It's simply hard to change at this late date without breaking a
great deal of existing code. Far less intrusive changes have
been rejected because they "broke the Web". I doubt this will
ever be resolved in Javascript.

-- Scott

[Michael Haufe (TNO)]

On Monday, December 29, 2014 2:15:57 AM UTC-6, lew...@gmail.com wrote:

> I was wondering today why undefined has not been made a reserved word even in newer versions of Javascript [...]

In ES5 it is read only. You can shadow it though...

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/undefined>

<http://www.ecma-international.org/ecma-262/5.1/#sec-15.1.1.3>