| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
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. |
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
On Feb 21, 7:09*am, David Mark <dmark.cins...@gmail.com> wrote:
> ideally some of those references > should have been written:- > > (global.window || global) > I think (and I told before) that such constructions for the sake of doubtful pleasure to show that you know that `global' is a built-in native object and `window' is a host object are really heavy overhead. And hoping and preparing (and writing) such scripts for any (?, ha  )host environment as useless as such ugly constructions which makes the code overloaded and heavy as (were mentioned here above and the last similar discussion) you don't have any idea what will `alert' do in completely different environment. P.S.: and yeah, still repeat, my meaning that for the *concrete* _browser host environment_, it's more useful to write simple plain `alert' without any prefix and regardless what base it has - `global' or `window' (which varies as you know in some implementations). /ds |
|
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
On Feb 21, 5:37*am, Stoyan <sst...@gmail.com> 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 |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On Feb 21, 3:37*am, Stoyan <sst...@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. |
|
|
|
|
|||
|
Guest
Posts: n/a
|
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). |
|
|
|
|
|||
|
Guest
Posts: n/a
|
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$> ? 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 |
|
|
|
|
|||
|
Guest
Posts: n/a
|
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$> > > ? 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. |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Initialize global variable before any other global variables | jubelbrus | C++ | 5 | 07-20-2007 06:38 PM |
| Are global functions methods of the global object? | User1014 | Javascript | 3 | 12-01-2006 01:02 PM |
| 501 PIX "deny any any" "allow any any" Any Anybody? | Networking Student | Cisco | 4 | 11-16-2006 10:40 PM |
| FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP | Hoffa | Cisco | 1 | 10-25-2006 06:50 PM |
| FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP | Hoffa | Cisco | 0 | 10-25-2006 01:04 PM |
