get the global object in any environment

[Stoyan]

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.

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`

Another hacky idea is to call a function that assumes global when
`this` is unusable. Andrea Giammarchi came up with the shortest form
(http://twitter.com/WebReflection/status/9406207674)
var global = [].sort.call(null);

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

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

Thoughts?

Thanks,
Stoyan

 

[Thomas 'PointedEars' Lahn]

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.

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`

Have you seen a single conforming implementation of ES5, in particular have
you seen a widely distributed one that supports strict mode yet? If yes,
which one? If no, why bother now? (JFYI: It took almost 10 years for ES3F
to be widely implemented. Why do you expect ES5 to be any faster?)

Besides, I doubt this has anything to do with constructors.

Another hacky idea is to call a function that assumes global when
`this` is unusable. Andrea Giammarchi came up with the shortest form
(http://twitter.com/WebReflection/status/9406207674)
var global = [].sort.call(null);

Very efficient; very compatible, too. NOT.

The question is - is that ES5 strict-safe?

Read the Specification for yourself (for a change). Ask smart questions
here if anything you read is still unclear.

Or any other ideas how to get access to the global without hardcoding
its name?

What exactly do you mean by "the global"?

Of course alternatively the new environment could simply define window
and problem is solved.

What hypothetical new environment are you talking about? Why should any
non-browser environment implement a property that only makes sense in a
browser environment?

E.g. if in some environment the global object is called `foo`,

Objects do not have names, they have an identity each.

then just do a global var window = foo; and call it a day

Thoughts?

var _global = this;

in the global execution context.

(In my JSX since quite a few years. Newer versions introduced `jsx.global'
as in-library reference -- locally aliased to jsx_global where reasonable
-- to avoid possible incompatibilities with other libraries.)

Do you realize that this is recommended literally on the first page of the
Core JavaScript 1.5 Reference?


PointedEars

 

[Stoyan]

Thanks Thomas!

Have you seen a single conforming implementation of ES5, in particular have
you seen a widely distributed one that supports strict mode yet?  If yes,
which one?  If no, why bother now?  (JFYI: It took almost 10 years for ES3F
to be widely implemented.  Why do you expect ES5 to be any faster?)

Good point. But we can hope

Another hacky idea is to call a function that assumes global when
`this` is unusable. Andrea Giammarchi came up with the shortest form
(http://twitter.com/WebReflection/status/9406207674)
var global = [].sort.call(null);

Very efficient; very compatible, too.  NOT.

You're right. Not Andrea's fault, he just make my clumsy version much
shorter.
What I had was worse:
var global = function(){var x;return(x=[].sort)()}();

Read the Specification for yourself (for a change).  Ask smart questions
here if anything you read is still unclear.

Thanks, I'll ask

What exactly do you mean by "the global"?

I meant "the global object"

What hypothetical new environment are you talking about?  Why should any
non-browser environment implement a property that only makes sense in a
browser environment?

What I had in mind was - say you're building a library and it's so
useful it makes sense to use the same library in other environments,
not only the browser. For example you can do server-side scripts or
write photoshop scripts. The photoshop environment for example doesn't
have `window`, but it does have a global `app`.

In such cases when you use a library which uses `window` to refer to
the global object, you can probably do
var window = this;
and the library should work

  var _global = this;

in the global execution context.

I was thinking about when not in the global context? Say your library
has a function and inside that function you want check the global
namespace for something. Probably to far-fetched case, I don't know.

I guess a good approach for a library is to store a global reference
for future internal use, just like you suggested.

var MyLib = function() {
// my whole lib is here,
// no other global vars leaked

return {
someMethod: function() {
var g = MyLib._global;
//...
}
};
}();
MyLib._global = this;

This way someMethod() doesn't need to figure out access to the global
object on its own.


Thanks again for your reply!

Stoyan

 

[David Mark]

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.
Indeed.

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.

Definitely a bad idea.

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`
Right.


Another hacky idea is to call a function that assumes global when
`this` is unusable. Andrea Giammarchi came up with the shortest form
(http://twitter.com/WebReflection/status/9406207674)
var global = [].sort.call(null);

Hack-y is right.

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

I imagine it is not going to foul up ES5 strict mode.

Of course alternatively the new environment could simply define window
and problem is solved.

It isn't up to a random environment to solve issues specific to your
script.

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

No need to do anything like that (and it would certainly cause issues in
_browsers_). And what makes you think there will even be a global
property (e.g. foo) that references the Global Object? That's what the
- this - identifier is for (in the global context).

Thoughts?

Why not just do this in the global context:-

var global = this;

....and call it a day.

That's what I did in My Library, which has no unqualified - window -
references. Come to think of it, it has no such _qualified_ references
either, which I don't consider ideal. So as not to assume that the
Global Object is the window object (despite the fact that it has been
observed to be in many browsers), ideally some of those references
should have been written:-

(global.window || global)

The determining factor is whether they are used to qualify references to
properties that are known to be specific to the window object in
browsers (e.g. the alert method).

Of course, this is another case where the declaration of a global -
window - variable could cause problems (e.g. if it did not reference the
Global Object). Trying to make other environments look like browsers is
just as bad an idea as trying to make IE look like a quasi-standard
browser (as seen in at least one misguided library).

Such environmental differences can be important, depending on context,
so should not be arbitrarily spackled over. See also jQuery's
height/width methods, which on gets seek to make every element look like
it uses the one box model its developers consider to be "correct". They
didn't bother to mirror these contortions for set operations, so
basically they return dimensions that are of no practical use unless the
element's box model happens to be the "correct" one.

 

[Thomas 'PointedEars' Lahn]

Thanks Thomas!

Thank you for keeping proper attribution next time.

[Thomas 'PointedEars' Lahn wrote:]

[Stoyan wrote:]

Or any other ideas how to get access to the global without hardcoding
its name?

What exactly do you mean by "the global"?

I meant "the global object"

Then, as I said, objects do not have names.

What hypothetical new environment are you talking about? Why should any

What I had in mind was - say you're building a library and it's so
useful it makes sense to use the same library in other environments,
not only the browser. For example you can do server-side scripts or
write photoshop scripts. The photoshop environment for example doesn't
have `window`, but it does have a global `app`.

In such cases when you use a library which uses `window` to refer to
the global object, you can probably do
var window = this;
and the library should work

You are still having the misconception that anything other than `this' in
the global execution context is supposed to refer to the ECMAScript Global
Object.

I was thinking about when not in the global context?

Then you use the global variable or any other property that stores the
appropriate value. Preferably you would assign the value to a local
variable if you used it repeatedly, to keep the effective scope chain
short.

Say your library has a function and inside that function you want check
the global namespace for something. Probably to far-fetched case, I
don't know.

Not at all, I am doing this already, for example in my URI-escape wrapper
in string.js.

I guess a good approach for a library is to store a global reference
for future internal use, just like you suggested.

var MyLib = function() {
// my whole lib is here,
// no other global vars leaked

What you state in the comment is not entirely true; if MyLib is global, any
code can access MyLib._global. However, you could it make so, of course:

var MyLib = (function(global) {
/* global */
})(this);

return {
someMethod: function() {
var g = MyLib._global;
//...
}
};
}();
MyLib._global = this;

Or something less ugly. The namespacing approach is heavily overrated
(and over-used) to begin with.

This way someMethod() doesn't need to figure out access to the global
object on its own.

It does not really matter how you access that object value, only that it is
available in the relevant execution contexts.

Thanks again for your reply!
[snip]

You are welcome. Thank you in advance for quoting properly next time.

<http://jibbering.com/faq/#posting>


PointedEars

 

[Thomas 'PointedEars' Lahn]

Why not just do this in the global context:-

var global = this;

...and call it a day.

That's what I did in My Library, which has no unqualified - window -
references. Come to think of it, it has no such _qualified_ references
either, which I don't consider ideal. So as not to assume that the
Global Object is the window object (despite the fact that it has been
observed to be in many browsers), ideally some of those references
should have been written:-

(global.window || global)

Ouch.


PointedEars

 

[David Mark]

Ouch.

And what do we consider to be painful about that? You snipped my
disclaimer.

(global.window || global).alert('Hello from any environment'); // see
previous disclaimer

If you simply use global.alert, you are assuming that - window - and the
Global Object are the same thing (and I know you don't promote that
assumption). So what's your line?

 

[Thomas 'PointedEars' Lahn]

And what do we consider to be painful about that? You snipped my
disclaimer.

Your disclaimer is nonsense.

(global.window || global).alert('Hello from any environment'); // see
previous disclaimer

As is this.

If you simply use global.alert, you are assuming that - window - and the
Global Object are the same thing (and I know you don't promote that
assumption).

Yes, you are, by this very construction.

So what's your line?

Don't.


PointedEars

 

[David Mark]

Your disclaimer is nonsense.

Is it? ISTM that if you declare a global - window - variable, you are
going to screw it up. No?

As is this.

I think not. A non-browser may well feature a global alert method, just
as some have been demonstrated to feature a global setTimeout method,
but no global window object.

Yes, you are, by this very construction.

I don't think you understood what I was demonstrating. If there is a
global window property (as in browsers), it will be used. If not, it
will use the reference to the Global Object. Obviously, feature
detection has been omitted from the example, but that doesn't seem to be
your beef.

Don't.

I meant your line of _code_ for calling alert (or setTimeout or
whatever) in an environment-agnostic fashion.

 

[Thomas 'PointedEars' Lahn]

Is it? ISTM that if you declare a global - window - variable, you are
going to screw it up. No?

AFAIR, nobody suggested doing that. (And yes, you are going to screw up in
the environments we know about. But this is about unknown environments, is
it not?)

I think not. A non-browser may well feature a global alert method, just
as some have been demonstrated to feature a global setTimeout method,
but no global window object.

And if my grandmother had wheels, she'd be a motorcycle. See below.

I don't think you understood what I was demonstrating. If there is a
global window property (as in browsers), it will be used. If not, it
will use the reference to the Global Object. Obviously, feature
detection has been omitted from the example, but that doesn't seem to be
your beef.

Are you really asking what problems I have with this code? Well, I do not
quite know where to begin.

Missing feature detection is only one part of my criticism: A type-
converting test involving an unknown potential host object and you can find
nothing wrong with it? And have we not established by now that one does
not grow reference worms, particularly not with method calls unless we know
for sure that the MemberExpression left-hand side can evaluate to a fitting
object reference, and particularly not if the code is exposed to unknown
runtime environments?

The other part is, of course, your readily jumping to conclusions here.

First of all, you should rest assured you do not know *anything* about
unknown environments (else they would not be unknown, would they?), so all
your talk about "properties that are known to be specific to the window
object in browsers" does not make any sense in that context. It is really
apples and oranges. Whereas you have not even tried to address the
question which browsers you are actually talking about here. Keep in mind
that we are talking about a host object here, so it can have (and evidently
has) different properties in different browsers, including those that you
do not yet know.

Then, if you assume that the two expressions refer to different objects
instead of the same (else you would not need the OR operation in the first
place), where did the global object of the other environment suddenly get
the magic alert() method from?

And that aside, why would you even expect such a method to work the same as
the method defined for Window instances from a completely different runtime
environment to begin with -- because the property has the same name? What
does, for example, the implementor of an ECMAScript implementation for an
e-book reader need to care what your favorite Web browser implements, and
how it does that? Suppose, just suppose, it would work remotely the same
as in that Web browser (i.e. it displayed a message to the user, and would
not, e.g. log it to a file in the reader's filesystem -- or the book
server's? -- instead): All things considered it could require, for example,
a second argument to indicate the message title, a third for the message
type aso., and throw a TypeError when those are missing (or `undefined').
Or the order of expected arguments could be reversed or interchanged. Or
it could take no arguments at all. Or it could only be called under
certain circumstances. Or ... And then -- what?

I meant your line of _code_ for calling alert (or setTimeout or
whatever) in an environment-agnostic fashion.

As you can hopefully see by now, there can be no such thing. The very
definition of "proprietary" precludes any reasonable assumptions about the
availability or functionality of such features in runtime environments with
ECMAScript binding that one knows nothing about.


PointedEars

 

[Asen Bozhilov]

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.

 

[Dmitry A. Soshnikov]

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

 

[Dmitry A. Soshnikov]

var global = [].sort.call(null);

Oh, that's too pervert and sophisticated

Be simpler, three good alternatives were shown above - just global
variable with `this' value, passing `this' as argument to your
encapsulating context and applying it via call/apply.

/ds

 

[Jorge]

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]

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]

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]

Stoyan

Stefanov ? Ha ! thanks for this one !

http://www.phpied.com/javascript-shell-scripting/



$ jsc

for (var p in this) { print(p); }

p
EvalError
RangeError
ReferenceError
SyntaxError
TypeError
URIError
debug
print
quit
gc
version
run
load
checkSyntax
readline
arguments
undefined

 

[David Mark]

AFAIR, nobody suggested doing that. (And yes, you are going to screw up in
the environments we know about. But this is about unknown environments, is
it not?)

It is about writing a script that will work in non-browsers, as well as
browsers. And yes, the OP did suggest declaring a global - window -
variable and "calling it a day".

And if my grandmother had wheels, she'd be a motorcycle. See below.

That would seem to imply that she is a wheel-less motorcycle at present.

Are you really asking what problems I have with this code? Well, I do not
quite know where to begin.

Whatever. It's one line of example code.

Missing feature detection is only one part of my criticism: A type-
converting test involving an unknown potential host object and you can find
nothing wrong with it?

See above.

And have we not established by now that one does
not grow reference worms, particularly not with method calls unless we know
for sure that the MemberExpression left-hand side can evaluate to a fitting
object reference, and particularly not if the code is exposed to unknown
runtime environments?

See above. Obviously you wouldn't use that code verbatim in production.

The other part is, of course, your readily jumping to conclusions here.

First of all, you should rest assured you do not know *anything* about
unknown environments (else they would not be unknown, would they?), so all
your talk about "properties that are known to be specific to the window
object in browsers" does not make any sense in that context.

Of course it does. If we are dealing with a global - window - property,
then we are dealing with something that is at least trying to look like
a browser (and likely is a browser).

It is really
apples and oranges. Whereas you have not even tried to address the
question which browsers you are actually talking about here.

All browsers. They've all got windows.

Keep in mind
that we are talking about a host object here, so it can have (and evidently
has) different properties in different browsers, including those that you
do not yet know.

Yes, as mentioned, I didn't include any feature detection in the example.

Then, if you assume that the two expressions refer to different objects
instead of the same (else you would not need the OR operation in the first
place), where did the global object of the other environment suddenly get
the magic alert() method from?

Same place that non-browsers get the "magic" setTimeout and setInterval
methods.

And that aside, why would you even expect such a method to work the same as
the method defined for Window instances from a completely different runtime
environment to begin with -- because the property has the same name?

A global alert method? I would certainly think it would - at the very
least - display a text message in some way.

What
does, for example, the implementor of an ECMAScript implementation for an
e-book reader need to care what your favorite Web browser implements, and
how it does that?

If they define a global alert method, I think its purpose can be inferred.

Suppose, just suppose, it would work remotely the same
as in that Web browser (i.e. it displayed a message to the user, and would
not, e.g. log it to a file in the reader's filesystem -- or the book
server's? -- instead):

That would be perfectly appropriate for an alert on the server.

All things considered it could require, for example,
a second argument to indicate the message title, a third for the message
type aso., and throw a TypeError when those are missing (or `undefined').

It could, but that would be foolish on the part of the implementors.

Or the order of expected arguments could be reversed or interchanged.

That's even more foolish (and less likely). They'd be asking for
trouble (and who wants trouble?)

Or
it could take no arguments at all.

That would make the least amount of sense for an - alert - method.

Or it could only be called under
certain circumstances. Or ... And then -- what?

You are reaching.

As you can hopefully see by now, there can be no such thing.

There are no guarantees with this stuff. There never have been, even in
browsers. You have to know your history, use sound feature detection
and still things can go wrong.

The very
definition of "proprietary" precludes any reasonable assumptions about the
availability or functionality of such features in runtime environments with
ECMAScript binding that one knows nothing about.

You can say the same thing about _browser_ host objects, yet viable
cross-browser scripts are written every day (and have been for a decade).

 

[Thomas 'PointedEars' Lahn]

It is about writing a script that will work in non-browsers, as well as
browsers.

AISB, there can be no such script if it employs proprietary features.
Indeed, it is questionable whether there can ever be such a script written
in an ECMAScript implementation even if it only employs specified features
as what is specified does not need exactly be what is implemented,
conforming implementations can be of different Editions of ECMAScript, and
implementations have bugs with regard to the Edition they supposedly
implement, too.

And yes, the OP did suggest declaring a global - window -
variable and "calling it a day".

Granted, he did; however, I did not, and your suggestion is not any better
than his.

Of course it does. If we are dealing with a global - window - property,
then we are dealing with something that is at least trying to look like
a browser (and likely is a browser).
No.


All browsers. They've all got windows.
No.


Yes, as mentioned, I didn't include any feature detection in the example.

Feature detection cannot remedy the intrinsic problem of this approach.

Same place that non-browsers get the "magic" setTimeout and setInterval
methods.
Nonsense.


A global alert method? I would certainly think it would - at the very
least - display a text message in some way.


If they define a global alert method, I think its purpose can be
inferred.

You are mistaken (in both assumptions).

That would be perfectly appropriate for an alert on the server.

And you do not find that ambiguity of your code a little bit disturbing?

It could, but that would be foolish on the part of the implementors.

No, it would not; how did you get that crazy idea after all, considering

| It isn't up to a random environment to solve issues specific to your
| script.
-- David Mark in <
?

The implementation needs to satisfy the capabilities of the runtime
environment in which it is used; not the capabilities of some other
environment in which it is not used, only because some people jump to
conclusions about the availability of certain features.

That's even more foolish (and less likely). They'd be asking for
trouble (and who wants trouble?)
Nonsense.


That would make the least amount of sense for an - alert - method.

No, there could be general behavior that does not need an argument.

You are reaching.

No, you are. Browsers have nothing to do with non-browsers. That much is
self-evident.

There are no guarantees with this stuff. There never have been, even in
browsers. You have to know your history, use sound feature detection
and still things can go wrong.

Non sequitur. It is foolish to assume that things would work the same
everywhere.

You can say the same thing about _browser_ host objects, yet viable
cross-browser scripts are written every day (and have been for a decade).

Yes, cross-*browser*, limited to known implementations in browsers,
sometimes even only a set of known browsers. Implementations based on a
common history of environments and implementations, where some generally
useful proprietary features became de facto standards *for browsers*, and
by that some even became standards that are independent of the runtime
environment or the used programming language.

IOW, it is not reasonable to assume that `if (x) ;' would break in code
written in a ECMAScript implementation in a non-browser when it worked in a
browser ECMAScript implementation in a browser. But it is very reasonable
to assume that `alert(...)' would either break or do something different
than in a browser, in a non-browser environment. It is therefore not
reasonable to insist that working scripts could be written to call such a
method independently of the runtime environment.


PointedEars

 

[David Mark]

AISB, there can be no such script if it employs proprietary features.
Indeed, it is questionable whether there can ever be such a script written
in an ECMAScript implementation even if it only employs specified features
as what is specified does not need exactly be what is implemented,
conforming implementations can be of different Editions of ECMAScript, and
implementations have bugs with regard to the Edition they supposedly
implement, too.


Granted, he did; however, I did not, and your suggestion is not any better
than his.

Are you saying the OP is a nobody?

And my primary suggestion was virtually identical to yours (save for an
underscore in front of your global variable). Now you are going on
about an aside.

No.

Whatever. Seems like an odd choice to define a global - window -
property if you are not advertising at least some sort of browser-like
compatibility.

No.

Some browsers do not have windows? That would be news.

Feature detection cannot remedy the intrinsic problem of this approach.

But you cited its absence as one of your gripes.

Nonsense.

There are documented cases of non-browsers with global
setTimeout/setInterval methods and they work as you would expect them to
work in browsers. So what are you trying to say?

You are mistaken (in both assumptions).

I only mentioned one inference.

And you do not find that ambiguity of your code a little bit disturbing?

Of course not. Where else would the message go on the server? Surely
not to the display.

No, it would not; how did you get that crazy idea after all, considering

| It isn't up to a random environment to solve issues specific to your
| script.
-- David Mark in <
?

Apples and oranges. I was referring to the idea that all host
environments should define a global - window - property.

The implementation needs to satisfy the capabilities of the runtime
environment in which it is used; not the capabilities of some other
environment in which it is not used, only because some people jump to
conclusions about the availability of certain features.

Right, so some environments may send the message to an LCD display or
speak it or log it or whatever is appropriate. The point is that an
alert method should be expected to convey a text message.

Nonsense.

You are starting to sound like a broken record (and who wants broken
records?)

No, there could be general behavior that does not need an argument.

Wouldn't be prudent.

No, you are. Browsers have nothing to do with non-browsers. That much is
self-evident.

Yes, but there are always inferences involved with this stuff. You
can't do much of anything without inferring something.

Non sequitur. It is foolish to assume that things would work the same
everywhere.

I think you are over-generalizing what I am saying.

Yes, cross-*browser*, limited to known implementations in browsers,
sometimes even only a set of known browsers.

A set of known browsers would instead indicate a multi-browser script.

Implementations based on a
common history of environments and implementations, where some generally
useful proprietary features became de facto standards *for browsers*, and
by that some even became standards that are independent of the runtime
environment or the used programming language.

Yes, and the implementors of the relatively rare non-browser host
environments have that history to consider. They'd be foolish to
completely ignore it and redefine things such as alert to - for example
- ignore the first argument and display the same message every time.

IOW, it is not reasonable to assume that `if (x) ;' would break in code
written in a ECMAScript implementation in a non-browser when it worked in a
browser ECMAScript implementation in a browser. But it is very reasonable
to assume that `alert(...)' would either break or do something different
than in a browser, in a non-browser environment. It is therefore not
reasonable to insist that working scripts could be written to call such a
method independently of the runtime environment.

Perhaps setTimeout would be a better example as it has been demonstrated
to exist in non-browsers and to work in the expected fashion. What sort
of implementor would define that same method to do something different?
Sounds like designing for failure to me.

And this is all academic anyway. Who actually writes such scripts? As
we know, context is everything and even generalized _browser_ scripts
are considered a bad idea, so the whole argument is out there.