get the global object in any environment

Discussion in 'Javascript' started by Stoyan, Feb 21, 2010.

  1. Stoyan

    Stoyan Guest

    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
    Stoyan, Feb 21, 2010
    #1
    1. Advertising

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

    > 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
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #2
    1. Advertising

  3. Stoyan

    Stoyan Guest

    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 :)

    >
    > > 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"

    > > 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?
    >



    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


    > > Thoughts?

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

    > (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
    > --
    > var bugRiddenCrashPronePieceOfJunk = (
    >     navigator.userAgent.indexOf('MSIE 5') != -1
    >     && navigator.userAgent.indexOf('Mac') != -1
    > )  // Plone, register_function.js:16
    Stoyan, Feb 21, 2010
    #3
  4. Stoyan

    David Mark Guest

    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.


    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.
    David Mark, Feb 21, 2010
    #4
  5. Stoyan wrote:

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

    >> > 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?

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

    >> > Thoughts?

    >>
    >> var _global = this;
    >>
    >> in the global execution context.

    >
    > 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
    --
    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
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #5
  6. David Mark wrote:

    > 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
    --
    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
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #6
  7. Stoyan

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> 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.


    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?
    David Mark, Feb 21, 2010
    #7
  8. David Mark wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> David Mark wrote:
    >>> 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.

    >
    > 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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #8
  9. Stoyan

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> David Mark wrote:
    >>>> 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.

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

    >
    > Your disclaimer is nonsense.


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

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

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

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


    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.

    >
    >> So what's your line?

    >
    > Don't.
    >


    I meant your line of _code_ for calling alert (or setTimeout or
    whatever) in an environment-agnostic fashion.
    David Mark, Feb 21, 2010
    #9
  10. David Mark wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> David Mark wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> David Mark wrote:
    >>>>> 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.
    >>> And what do we consider to be painful about that? :) You snipped my
    >>> disclaimer.

    >>
    >> Your disclaimer is nonsense.

    >
    > 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?)

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

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


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

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

    >
    > 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?

    >>> So what's your line?

    >> Don't.

    >
    > 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
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #10
  11. 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.
    Asen Bozhilov, Feb 21, 2010
    #11
  12. On Feb 21, 7:09 am, David Mark <> 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
    Dmitry A. Soshnikov, Feb 21, 2010
    #12
  13. On Feb 21, 5:37 am, Stoyan <> wrote:

    <snip>

    >
    > 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
    Dmitry A. Soshnikov, Feb 21, 2010
    #13
  14. Stoyan

    Jorge Guest

    On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <>
    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.
    Jorge, Feb 21, 2010
    #14
  15. Stoyan

    Jorge Guest

    On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <>
    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.
    Jorge, Feb 21, 2010
    #15
  16. Stoyan

    Jorge Guest

    On Feb 21, 4:13 am, Thomas 'PointedEars' Lahn <>
    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.
    Jorge, Feb 21, 2010
    #16
  17. Stoyan

    Jorge Guest

    On Feb 21, 3:37 am, Stoyan <> wrote:
    >
    > 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
    --
    Jorge.
    Jorge, Feb 21, 2010
    #17
  18. Stoyan

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> David Mark wrote:
    >>>> Thomas 'PointedEars' Lahn wrote:
    >>>>> David Mark wrote:
    >>>>>> 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.
    >>>> And what do we consider to be painful about that? :) You snipped my
    >>>> disclaimer.
    >>> Your disclaimer is nonsense.

    >> 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?)


    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". :)

    >
    >>>> (global.window || global).alert('Hello from any environment'); // see
    >>>> previous disclaimer
    >>> 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.

    >
    > 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. :)

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

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


    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.

    >
    >>>> So what's your line?
    >>> Don't.

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


    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).
    David Mark, Feb 21, 2010
    #18
  19. David Mark wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> David Mark wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> David Mark wrote:
    >>>>> Thomas 'PointedEars' Lahn wrote:
    >>>>>> David Mark wrote:
    >>>>>>> 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.
    >>>>> And what do we consider to be painful about that? :) You snipped my
    >>>>> disclaimer.
    >>>> Your disclaimer is nonsense.
    >>> 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?)

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

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


    No.

    >> 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. ;)


    No.

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


    Feature detection cannot remedy the intrinsic problem of this approach.

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


    Nonsense.

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


    You are mistaken (in both assumptions).

    >> 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. ;)


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

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


    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 <news:hlqbqi$l95$-september.org>

    ?

    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.

    >> 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?)


    Nonsense.

    >> Or it could take no arguments at all.

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


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

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

    >
    > You are reaching.


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

    >>>>> So what's your line?
    >>>> Don't.
    >>> 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.

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

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


    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
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Feb 21, 2010
    #19
  20. Stoyan

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> David Mark wrote:
    >>>> Thomas 'PointedEars' Lahn wrote:
    >>>>> David Mark wrote:
    >>>>>> Thomas 'PointedEars' Lahn wrote:
    >>>>>>> David Mark wrote:
    >>>>>>>> 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.
    >>>>>> And what do we consider to be painful about that? :) You snipped my
    >>>>>> disclaimer.
    >>>>> Your disclaimer is nonsense.
    >>>> 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?)

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


    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.

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

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

    >
    >>> 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. ;)

    >
    > No.


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

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

    >
    > Feature detection cannot remedy the intrinsic problem of this approach.


    But you cited its absence as one of your gripes.

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

    >
    > 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?

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

    >
    > You are mistaken (in both assumptions).


    I only mentioned one inference. :)

    >
    >>> 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. ;)

    >
    > 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. ;)

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

    >
    > 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 <news:hlqbqi$l95$-september.org>
    >
    > ?


    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.

    >
    >>> 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?)

    >
    > Nonsense.


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

    >
    >>> Or it could take no arguments at all.

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

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


    Wouldn't be prudent.

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

    >> You are reaching.

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

    >
    >>>>>> So what's your line?
    >>>>> Don't.
    >>>> 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.

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


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

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

    >
    > 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.
    David Mark, Feb 21, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    640
  2. jubelbrus
    Replies:
    5
    Views:
    602
    JohnQ
    Jul 20, 2007
  3. Steve Chatham

    global.asa in dotnet environment

    Steve Chatham, Jan 29, 2004, in forum: ASP General
    Replies:
    0
    Views:
    126
    Steve Chatham
    Jan 29, 2004
  4. Ludwigi Beethoven
    Replies:
    0
    Views:
    81
    Ludwigi Beethoven
    Aug 24, 2003
  5. User1014
    Replies:
    3
    Views:
    183
    Richard Cornford
    Dec 1, 2006
Loading...

Share This Page