From: Asen Bozhilov on
Stoyan wrote:
> Hi group,
>
> Since JS is everywhere (client, server, desktop...), it makes sense to
> think how to write code that could run in environments other than the
> one originally in mind. Perhaps it's not a good idea to use `window`
> when the code could possibly run in environment that has no idea what
> `window` is.

`this' value associated with global execution context, always refer
Global Object.

| 10.2.1 Global Code
| * The scope chain is created and initialised to contain
| the global object and no others.
| * Variable instantiation is performed using the
| global object as the variable object and using
| property attributes {DontDelete}.
| * The this value is the global object.

> so this pattern came to mind:
> var global = function(){return this;}();
> However this apparently won't work in ES5 strict which aims to prevent
> errors from calling constructors without `new`

Misconception. If i define *constructor* I'll expect user, which use
my code to follow my recommendation. If he don't know what doing,
perhaps is good to read documentation. If he expect magic codes and
interpreter, which pay attention about his mistakes and
misconceptions, i am cannot do it anything about his expectations.

I have question. ES5 strict mode make sense when *constructor* been
invoked as function call, but what is behavior if someone call my
methods with `new' operator?


> The question is - is that ES5 strict-safe? Or any other ideas how to
> get access to the global without hardcoding its name?

var MyLib = (function()
{
/* this value associated with newly
* created execution context
* will refer Global Object
*/
}).call(this);

Of course call stack is with one level bigger from `FunctionCall`, but
that code will work in both ES3 and ES5 implementations, independently
from mode variant in ES5.

> Of course alternatively the new environment could simply define window
> and problem is solved. E.g. if in some environment the global object
> is called `foo`, then just do a global var window = foo; and call it a
> day :)

In ECMA 262 standard, there are no property in Scope Chain which refer
Global Object. If implementation provide property in Scope Chain,
which refer Global Object that isn't quirks environment, because the
standard permit similar behavior from:

| 2 Conformance
| In particular, a conforming implementation of
| ECMAScript is permitted to provide properties
| not described in this specification,
| and values for those properties,
| for objects that are described in this specification.

Regards.
From: Dmitry A. Soshnikov on
On Feb 21, 7:09 am, David Mark <dmark.cins...(a)gmail.com> wrote:

> ideally some of those references
> should have been written:-
>
> (global.window || global)
>

I think (and I told before) that such constructions for the sake of
doubtful pleasure to show that you know that `global' is a built-in
native object and `window' is a host object are really heavy overhead.

And hoping and preparing (and writing) such scripts for any (?, ha ;))
host environment as useless as such ugly constructions which makes the
code overloaded and heavy as (were mentioned here above and the last
similar discussion) you don't have any idea what will `alert' do in
completely different environment.

P.S.:

and yeah, still repeat, my meaning that for the *concrete* _browser
host environment_, it's more useful to write simple plain `alert'
without any prefix and regardless what base it has - `global' or
`window' (which varies as you know in some implementations).


/ds
From: Jorge on
On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Stoyan wrote:
> > Since JS is everywhere (client, server, desktop...), it makes sense to
> > think how to write code that could run in environments other than the
> > one originally in mind. Perhaps it's not a good idea to use `window`
> > when the code could possibly run in environment that has no idea what
> > `window` is.
>
> Sigh. [psf 10.1]  It has *never* been a good idea to use a proprietary,
> host-defined property, that is supposed to refer to a host object to access
> a different, standardized, native object.  But some people just would not
> listen.

ECMA 262, 3rd edition, 10.1.5, Global Object:
There is a unique global object (15.1), which is created before
control enters any execution context. Initially the global object has
the following properties:
• Built-in objects such as Math, String, Date, parseInt, etc. These
have attributes { DontEnum }.
• Additional host defined properties. This may include a property
whose value is the global object itself; for example, in the HTML DOM
the window property of the global object is the global object itself.
--
Jorge.
From: Jorge on
On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Stoyan wrote:
> > Since JS is everywhere (client, server, desktop...), it makes sense to
> > think how to write code that could run in environments other than the
> > one originally in mind. Perhaps it's not a good idea to use `window`
> > when the code could possibly run in environment that has no idea what
> > `window` is.
>
> Sigh. [psf 10.1]  It has *never* been a good idea to use a proprietary,
> host-defined property, that is supposed to refer to a host object to access
> a different, standardized, native object.  But some people just would not
> listen.

ECMA 262, ES5 FINAL, 15.1, The Global Object:

The unique global object is created before control enters any
execution context. Unless otherwise specified, the standard built-in
properties of the global object have attributes {[[Writable]]: true,
[[Enumerable]]: false, [[Configurable]]: true}. The global object does
not have a [[Construct]] internal property; it is not possible to use
the global object as a constructor with the new operator.
p 102 © Ecma International 2009
The global object does not have a [[Call]] internal property; it is
not possible to invoke the global object as a function.
The values of the [[Prototype]] and [[Class]] internal properties of
the global object are implementation- dependent.
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 DOM the window property of the global object is the global object
itself.
--
Jorge.
From: Jorge on
On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Stoyan wrote:
> > Since JS is everywhere (client, server, desktop...), it makes sense to
> > think how to write code that could run in environments other than the
> > one originally in mind. Perhaps it's not a good idea to use `window`
> > when the code could possibly run in environment that has no idea what
> > `window` is.
>
> Sigh. [psf 10.1]  It has *never* been a good idea to use a proprietary,
> host-defined property, that is supposed to refer to a host object to access
> a different, standardized, native object.  But some people just would not
> listen.

(globalObject).window === (globalObject).self === (globalObject)

Hope that helps,
--
Jorge.