get the global object in any environment
in [JavaScript]
|
Prev: How do I get keys from an associative array?
Next: instructor's solutions manual for Basic Electromagnetics with Applications by Nannapaneni Narayana Rao
From: Jorge on 21 Feb 2010 10:34 On Feb 21, 3:37 am, Stoyan <sst...(a)gmail.com> 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 quit gc version run load checkSyntax readline arguments undefined -- Jorge.
From: David Mark on 21 Feb 2010 14:57 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).
From: Thomas 'PointedEars' Lahn on 21 Feb 2010 15:37 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$1(a)news.eternal-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
From: David Mark on 21 Feb 2010 15:59 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$1(a)news.eternal-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.
From: Thomas 'PointedEars' Lahn on 21 Feb 2010 16:36
David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>>> [...] 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". :) >> >> Granted, he did; however, I did not, and your suggestion is not any >> better than his. > > Are you saying the OP is a nobody? :) Fallacy. The word "granted" should have given you some indication what my reply was about. > And my primary suggestion was virtually identical to yours (save for an > underscore in front of your global variable). But not what you made of it. > Now you are going on about an aside. Your fallacies in this matter are asides? Ah, maybe *that* is why I cannot take them seriously. >>>> 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. What do you consider "browser-like"? >>>> 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. See, even you can still learn something new 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. >>> 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. So what? >>>> 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. What are those "non-browsers"? > So what are you trying to say? That you are still jumping to conclusions. >>>> 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. ;) Then you are ready for a holiday. For a start, the browser-like alert() displayed for the *user* to see it, sometimes execution even stops until the user has *confirmed* it or closed the window it usually shows. >>>> 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$1(a)news.eternal-september.org> >> >> ? > > Apples and oranges. No. > I was referring to the idea that all host environments should define a > global - window - property. It isn't up to a random environment to satisfy your misconceptions about what it is supposed to do either. >> 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. No, it could be any message. But assuming a text message: Where would the message be displayed, to whom, when, how? You are ignoring these aspects completely. >>>> 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. In your humble opinion. >>>> 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. You can do worse with inferring too much. >>>>>>> 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. I have been pointing out to you the inevitable conclusion that you did not want to see. >>>> 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. After accepting this terminology, one must conclude that there is no such thing as a cross-browser script, because we can only ever know a subset of 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. > > Yes, and the implementors of the relatively rare non-browser host > environments Why would they be rare? When? Where? > have that history to consider. No, because they are not implementing for browsers. > 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. ;) Instead, foolishly act people like you who assume that everything must work the same everywhere, and those who would not make it so would be foolish. > 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. Logical fallacy: Appeal to ridicule. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004) |