Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > get the global object in any environment

Reply
Thread Tools

get the global object in any environment

 
 
Asen Bozhilov
Guest
Posts: n/a
 
      02-21-2010
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.
 
Reply With Quote
 
 
 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 7:09*am, David Mark <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 5:37*am, Stoyan <(E-Mail Removed)> 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
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 4:13*am, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
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.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 4:13*am, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
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.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 4:13*am, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
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.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 3:37*am, Stoyan <(E-Mail Removed)> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-21-2010
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).
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      02-21-2010
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$(E-Mail Removed)-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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-21-2010
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$(E-Mail Removed)-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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


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



Advertisments