While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert()" over "alert()".
I can't find any technical reason to make this distinction, and seems to
have a (tiny) amount overhead since window itself points to the global
object, hence, a circular reference.
(From everything I am reading, window is just a REFERENCE back to the
global object, as opposed to a separate object.)
Which brings me to two ideas:
a) Either I am wrong, and window is really its own augmented object
through a grammar I don't follow
b) The decision is based for stylistic reasons, to remind the coder that
"alert()" is provided by the host environment and is not part of the EMCA
script specification.
24  8171 
Jeremy J Starcher meinte:
While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert()" over "alert()".
In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
object, in browsers the window object. If somebody (deliberately or
accidentally) defines an alert function elsewhere in the scope chain, it
will be called instead. "window.alert()" leaves no room for speculation.
Gregor
-- http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie http://web.gregorkofler.com ::: meine JS-Spielwiese http://www.image2d.com ::: Bildagentur für den alpinen Raum
Gregor Kofler wrote:
Jeremy J Starcher meinte:
>While reading c.l.j, I've noticed that some people prefer and indeed
even recommend the use of "window.alert()" over "alert()".
In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
object, in browsers the window object.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
In fact, there is evidence to the contrary: MSHTML's creating "read-only"
properties of a host object in the scope chain to refer to element objects
representing elements with ID or name, also being available through the
`window' reference. But the Global Object is specified as a native object,
it has to implement the [[Put]] method exactly as it was specified; so that
cannot be the object referred to by `window', which exhibits said behavior
instead.
If somebody (deliberately or accidentally) defines an alert function
elsewhere in the scope chain, it will be called instead. "window.alert()"
leaves no room for speculation.
That is not the reason why. Because if someone declared `window' in the
scope chain before the Global Object (so as this would not refer to the
`window' property of the Global Object anymore), then the issue remained.
It is instead that it is unlikely that someone would do that.
To be absolutely sure, one would have to feature-test and use
global.window.alert(), with `global' being a globally defined reference to
the Global Object (var global = this), instead.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Gregor Kofler wrote:
>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>object, in browsers the window object.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
It does seem that the global object's "window" property holds a
reference to the global object itself in all current browsers, to the
point where a new browser would be causing itself problems by not
doing the same.
No standard, true, except de-facto standard.
In fact, there is evidence to the contrary: MSHTML's creating "read-only"
properties of a host object in the scope chain to refer to element objects
representing elements with ID or name, also being available through the
`window' reference.
They are equally available through the global object. They are not
ReadOnly as properties of the global/window object, though, only when
resolved through the scope chain.
But the Global Object is specified as a native object,
it has to implement the [[Put]] method exactly as it was specified; so that
cannot be the object referred to by `window', which exhibits said behavior
instead.
That, or IE doesn't follow the specification and implements [[Put]]
differently on the global object.
It does appear that MSHTML has an a step in the variable resolution
procedure that acts as if there is an object above the global object,
that holds those element-id properties. It also appears that reading
the properties directly off the global object will also give the
element with that id. This gives two ways to give the same result,
and the two are not equivalent.
Example:
<div id="foo">foo</div>
<script type="text/javascript">
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "[object],object,[object],object"
alert("foo" in window);
// alerts true
try { foo = 42; } catch(e) { alert(e.message); }
// alerts "Object doesn't support this property or method"
window.foo = "window.foo";
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "[object],object,window.foo,string"
</script>
<script type="text/javascript">
var foo = 37;
alert([foo, typeof foo, window.foo, typeof window.foo]);
// alerts "37,number,37,number"
// a function declaration also changes both.
</script>
Using the global object instead of "window" gives exactly the same
result (they are the same object, as reported by "==").
I.e., the scope-lookup appears to match page id's just before it
tests the global object. There may or may not be an object holding
the properties (I'm expecting that there isn't, and that they are
instead resolved by extending the lookup algorithm directly).
The property is not writable, but it does shadow the same property
in the global object.
It appears that the id-elements are *also* properties of the
global/window object, but these properties are not ReadOnly
and can be overwritten. After this, "foo" and "window.foo"
resolves to different values.
And further, if a variable or function with the same name is declared
in the global scope, "foo" no longer resolves to the element with that
id.
Even more interesting, the behavior depends on whether one reads the
property of the global objecct as an element before assigning it
another value:
<script type="text/javascript">
// window.bar = 42; // [1]
</script>
<div id="bar">bar</div>
<script type="text/javascript">
//alert([bar, typeof bar, window.bar, typeof window.bar]); // [2]
window.bar = "window.bar";
alert([bar, typeof bar, window.bar, typeof window.bar]);
// alerts "window.bar,string,window.bar,string"
</script>
In the above, if [2] is uncommented, the final alert changes
to "[object],object,window.bar,string". I.e., the action of
*reading* "bar" as the element with that id causes later
references to give the same result.
If [1] is also uncommented, the final alert changes back again.
I.e., if a property of the name is already on the global object
when the element is parsed and added to the DOM, then its name is
not resolved specially and it is not set on the global object.
Ok, this was a diversion. The point is: There global object and
the value of the "window" property of the global object is the
same object in MSHTML, just as in the other current browsers.
My bet is that you can expect that to stay true.
....
That is not the reason why. Because if someone declared `window' in the
scope chain before the Global Object (so as this would not refer to the
`window' property of the Global Object anymore), then the issue remained.
It is instead that it is unlikely that someone would do that.
To be absolutely sure, one would have to feature-test and use
global.window.alert(), with `global' being a globally defined reference to
the Global Object (var global = this), instead.
That's not being "absolutely sure". The "global" property could
equally well have been overwritten or shadowed, and it's probably even
more likely than someone shadowing "window" or "alert", since those
are well known global properties.
To be absolutely sure, you should create a reference to the global
object at the point where it is needed, so you don't rely on a binding
that could be overwritten or shadowed.
e.g.
var global = (function(){return this;})();
global.alert(global == global.window);
(which, by the way, alerts "true" in all the browsers I have available,
including in MSHTML :).
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Gregor Kofler wrote:
>>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>>object, in browsers the window object.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
It does seem that the global object's "window" property holds a
reference to the global object itself in all current browsers, to the
^^^^^^^^^^^^^^^^^^^^
point where a new browser would be causing itself problems by not
doing the same.
No standard, true, except de-facto standard.
That is exactly what I mean. *Exhaustive* research would have included at
least a list of the tested user agents that are deemed to be "current" by
the tester. And it would have to cover *all browsers* instead for the
discussed statement to be confirmed as generally true. It is confirmations
like yours that show such general assertions to be misleading and ultimately
irresponsible.
I am going to look into your other arguments later.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
That is exactly what I mean. *Exhaustive* research would have included at
least a list of the tested user agents that are deemed to be "current" by
the tester.
In this case the tested browser were:
IE 8 beta, Opera 9.52, Firefox 3.01 and Safari 3.1.2
all on Windows.
And it would have to cover *all browsers*
That's impossible, so it should select a subset of known browsers
that are considered relevant.
E.g., I would omit Links, since it has no scripting support at all.
I would probably also omit Netscape version 3, since its market share
is effectively zero.
But yes, this was not an exhaustive research. It was a quick-and-dirty
check against the most common browsers and browser-engines (I can't
check iCab, don't have a Mac).
The secondary point was to say that, as far as I know, there have not
yet been a browser engine with a more than 1% user share that has not
had the global object be equal to the object referenced by the global
object's "window" property. It was so in Netscape 2 (you can add that
to the tested cases), and no browsers since have dared change that. My
experience is not "exhaustive research", but I do believe it is more
than "wishful thinking".
And the primary point was that it did hold for IE.
instead for the discussed statement to be confirmed as generally
true. It is confirmations like yours that show such general
assertions to be misleading and ultimately irresponsible.
Find one cases where it isn't true, in a browser that has any
significant number of users, and I'll agree.
*Any* standard feature of browsers might be broken or differently
implemented in some version of obscure browser. Unless that obscure
browser stays broken and gains a significant market-share, it can
safely be ignored. It is the browser producer/user's responsibility
to get it fixed.
A non-standard feature with as widespread an adherence as the "window"
property can be treated as a standard feature. If a browser fails to
be compatible with everybody else, ot an extend that it is visible in
pages, that browser will be considered broken. A de-facto standard is
at least as strong a requirement as an official standard. Since it
became a de-facto standard because of a need for that feature, it's
more likely to be implemented correctly than less important parts
of an official standard (or IE wouldn't have gotten away with
letting "[2,].length" evaluate to 2 after all this time).
The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.window == globalObject).
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen wrote:
The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.window == globalObject).
However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Lasse Reichstein Nielsen wrote:
>The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.window == globalObject).
However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.
Ah, am I misreading the response:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Gregor Kofler wrote:
>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>object, in browsers the window object.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
if I interpret "this assertion" as being that the global object is the
window object in browsers? Is the assertion instead that the scope
chain ends in the global object?
Neither assertion would be based on wishful thinking. The latter would
be backed up by the ECMAScript standard.
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Lasse Reichstein Nielsen wrote:
>>The window property is a de-facto standard (as other things sometimes
called DOM level 0). I would say the burden of proof is on you to
exhibit just one significant case where a browser differs from the
de-facto standard of having (globalObject.window == globalObject).
However, that would be supporting a logical fallacy because I did not make
the general statement in question here. Certainly I have no intention to do
that.
Ah, am I misreading the response:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Gregor Kofler wrote:
>>In case of "alert()" JS will search through the scope chain, until an
alert-named function is found. It will finally end up at the global
^^^^^^^^ property ^^^^^^^^^^
>>object, in browsers the window object.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This assertion is based on wishful thinking, still not backed up by any
public standard or exhaustive research. You would be well-advised not to
advocate it.
if I interpret "this assertion" as being that the global object is the
window object in browsers? Is the assertion instead that the scope
chain ends in the global object?
No, but instead that "in [all] browsers [the global object was] the window
object". This is the result of the quantificational logical fallacy of
"proof by example" (because statement A is asserted to be true for example
subset B within set C, it is falsely asserted that it is/must be true for
all elements of C).
For example, a valid argument would have been "It will finally end up at the
global object, in *some* browsers the window object." This argument can be
discussed because the subset of browsers to which said property is asserted
to apply ("some") can be named, and the assertion can either be confirmed or
refuted for each element of that subset, and thereby for the entire subset.
Neither assertion would be based on wishful thinking.
Yes, the former would. The original author of that statement wishes the
statement to be (generally) true because, if so, that would make Web
development easier.
The latter would be backed up by the ECMAScript standard.
Correct, and this was not debated, of course.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
So... if I were to paraphrase and understand:
alert may refer to any property along the scope chain and thus, should
not be used alone.
In most major browsers, "window" refers to the global object, unless
overridden.
Any browser where window != the global object will have enough other
problems that it can be ignored.
You may create your own reference to the global variable and use that
instead via
var globalObject = this;
in the right context, but this has all the limitations of using 'window'
Jeremy J Starcher wrote:
So... if I were to paraphrase and understand:
You should have said "try to understand".
alert may refer to any property along the scope chain and thus, should
not be used alone.
Not just any property, but yes.
In most major browsers, "window" refers to the global object, unless
overridden.
No, in *some* browsers it *appears* as if that were the case. However, it
was overlooked that a host object includes the possibility to let it appear
so. (I was about to explain that in reply to Lasse's posting.)
Anyhow, "most" implies a majority, one which cannot be proven as such (what
do you consider to be a "major browser", especially given the time factor?).
Any browser where window != the global object will have enough other
problems that it can be ignored.
Utter nonsense. What matters here is that alert() is defined as a method of
proprietary Window host objects, not of the native standardized Global Object.
You may create your own reference to the global variable and use that
instead via
var globalObject = this;
Except that the Global Object is _not_ a variable, it is -- surprise! --
a (native) *object*. Only `globalObject' would be a variable here that
stores a reference to that object.
in the right context, but this has all the limitations of using 'window'
Correct. Lasse's suggestion to use the return value of an anonymous
function is generally the safer approach. However, it is also likely the
less efficient one.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jeremy J Starcher <r3***@yahoo.comwrites:
So... if I were to paraphrase and understand:
alert may refer to any property along the scope chain and thus, should
not be used alone.
Mnah .. I'd use it alone. Javascript is statically scoped, so you only
have to consider the variables in scope. I usually write code as
functions in the global scope, or inside one of those, so I control
every part of the scope chain until there. It's only someone
overwriting the global "alert" property that would worry me, and if
they do that, I'd assume it's on purpose (e.g., the Selenium test
framework which changes "alert" so that it can test code containing
alerts unsupervised).
In most major browsers, "window" refers to the global object, unless
overridden.
True.
Any browser where window != the global object will have enough other
problems that it can be ignored.
That's my opinion. Thomas disagrees.
You may create your own reference to the global variable and use that
instead via
var globalObject = this;
Feel free. I'd use "window", or if absolutely necessary,
"self". Thomas disagrees.
in the right context, but this has all the limitations of using 'window'
I think it's worse, because people learns not to overwrite or shadow
the "window" property.
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Lasse Reichstein Nielsen wrote:
>if I interpret "this assertion" as being that the global object is the
window object in browsers? Is the assertion instead that the scope
chain ends in the global object?
No, but instead that "in [all] browsers [the global object was] the window
object". This is the result of the quantificational logical fallacy of
"proof by example" (because statement A is asserted to be true for example
subset B within set C, it is falsely asserted that it is/must be true for
all elements of C).
Since proving anything about "all browsers" is impossible in practice,
that's not what should be expected. I.e., this should not be read as
mathematical logic - what normal people say rarely should. We are not
attempting to prove a universal quantification. Rather, this is
traditional inducitive science, where we posit a theory and gather
evidence to support it (or, if we are lucky, a concrete
counter-example to disprove it).
The theory is that in all browsers (capable of scripting) has a window
object that is equal to its global object.
The evidence is gathered by examining browsers. So far, no counter-
example has been found. Yes, the gathering of evidence is has not
been scientific or well documented, but again, we are not talking
rocket science. We are assuming so many other things as well.
And to counter your argument that one shouldn't use "alert" alone,
since it is proprietary and only specified on the window object:
So is the "window" property, so using "window.property" is equally
flawed. http://devedge-temp.mozilla.org/libr...ta-window.html
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Lasse Reichstein Nielsen wrote:
>>if I interpret "this assertion" as being that the global object is
the window object in browsers? Is the assertion instead that the
scope chain ends in the global object?
No, but instead that "in [all] browsers [the global object was] the
window object". This is the result of the quantificational logical
fallacy of "proof by example" (because statement A is asserted to be
true for example subset B within set C, it is falsely asserted that it
is/must be true for all elements of C).
Since proving anything about "all browsers" is impossible in practice,
.... one should not be making (general) statements about them in the first place.
[...] The theory is that in all browsers (capable of scripting) has a
window object that is equal to its global object.
The evidence is gathered by examining browsers.
Evidence would be something that proves something. A handful of selected
examples proves exactly nothing.
So far, no counter- example has been found.
Which is not proof of anything.
Yes, the gathering of evidence is has not been scientific or well
documented, but again, we are not talking rocket science.
In other words, you prefer playing Russian Roulette instead. Well, I don't.
There is a standards compliant way to refer to the Global Object that works
in several environments (in time there may be even a context-insensitive and
efficient one, given current standardization efforts), so it is not
necessary and it is ultimately irresponsible to rely on and advocate a
proprietary one defined only for HTML environments, if that.
We are assuming so many other things as well.
I try to reduce the assumptions that I am making with focusing on features
specified in standards and the application of proper feature-testing.
And to counter your argument that one shouldn't use "alert" alone, since
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
it is proprietary and only specified on the window object: So is the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^
"window" property, so using "window.property" is equally flawed.
http://devedge-temp.mozilla.org/libr...ta-window.html
I did not make this argument. In fact, I have said and showed on several
occasions that `window' and its properties should be feature-tested as well.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
>Lasse Reichstein Nielsen wrote:
>>Thomas 'PointedEars' Lahn writes:
No, but instead that "in [all] browsers [the global object was] the
window object". This is the result of the quantificational
logical fallacy of "proof by example" (because statement A is
asserted to be true for example subset B within set C, it is
falsely asserted that it is/must be true for all elements of C).
Since proving anything about "all browsers" is impossible in
practice,
... one should not be making (general) statements about them in the
first place.
Why not? If you label some specific example of computer software as a
"browser" then there is a set of criteria for "browser" that it should
satisfy, and so 'browsers', generally, can be said to satisfy those
criteria.
However, that would be reversing the argument. Yes, I could make up a
definition that every red dog is a "blue cat", and then say rightfully
that per my definition all "blue cats" are red. But this leads nowhere.
>>[...] The theory is that in all browsers (capable of scripting) has a
window object that is equal to its global object.
The evidence is gathered by examining browsers.
Evidence would be something that proves something.
That is only one of many meanings of "evidence", where others include
'support for a belief or induction'.
Belief belongs elsewhere, and induction does not apply here.
And the ability of "evidence" to "prove" anything has been strongly
disputed for a very long time now.
There are those who would disagree, most notably criminal investigators.
But it would appear you are playing the /advocatus diaboli/ here.
>A handful of selected examples proves exactly nothing.
No they don't, but calling for proof by exhaustive testing is not the
rout to truth either.
But it is. It shows that the argument was made with an impossible
distribution, and so that it was wrong to be used as an argument in the
first place.
Consider the widespread belief (and some would say "truth")) that the
speed of light is constant in a vacuum.
Apples, oranges.
>>So far, no counter- example has been found.
Which is not proof of anything.
It is proof of something; that (assuming an honest whiteness) the person
making the report is not aware of any counter-examples.
Fair enough.
How significant that may be depends quite a bit on who is making the
report. [...]
No, that would be a fallacy (/ipse dixit/).
>>Yes, the gathering of evidence is has not been scientific or well
documented, but again, we are not talking rocket science.
In other words, you prefer playing Russian Roulette instead. Well, I
don't.
That is an extreme characterisation of a position that you have little
choice in taking yourself to some degree or another.
Is it? Doing something that is based on a false conclusion can only turn
out to be harmful (unless it serves as a bad example to others). I prefer
not to resort to wishful thinking when developing software, and that
approach has served me well to date.
You have no choice but assume the truths of numerous generalisations that
have not been exhaustively tested.
Yes, I have. I could perform those tests myself, and on occasion I have
been doing (or at least trying to do) just that. But what matters is that I
make no jumps to conclusions like those we can see here.
>There is a standards compliant way to refer to the Global Object that
works in several environments (in time there may be even a
context-insensitive and efficient one, given current standardization
efforts), so it is not necessary and it is ultimately irresponsible to
rely on and advocate a proprietary one defined only for HTML
environments, if that.
<snip>
That is an irrelevance. The question is whether the - global object <=>
window - relationship holds for all web browsers, not whether there is a
better alternative to using it.
No, the question was what would be the more reliable way to refer to the
Global Object, and I am still not convinced that this is `window' when the
standard since its first edition and all (non-broken) implementations in all
environments so far support `this' in the global context (or its less
efficient and slightly less compatible equivalent of using the `this' value
as returned from an anonymous function).
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Richard Cornford wrote:
>That is only one of many meanings of "evidence", where others include
'support for a belief or induction'.
Belief belongs elsewhere, and induction does not apply here.
It does indeed belong. Inductive reasoning, using evidence to support
a theory, is the basis of science.
We are not talking mathematical induction, just as it's not
mathematical proofs we are after.
>And the ability of "evidence" to "prove" anything has been strongly
disputed for a very long time now.
There are those who would disagree, most notably criminal investigators.
But it would appear you are playing the /advocatus diaboli/ here.
I wouldn't think so.
"Evidence", as well as "proof", has different meaning in different
contexts. Three typical contexts are mathematics, the natural
sciences, and law.
The usage here is that of science. An accumulation of evidence does
indeed lead to an theory being accepted as valid.
However, it doesn't *prove* it in the mathematical sense. It is the
ability to actually mathematically prove a scientific theory that is
disputed (can't prove a positive). It's easy to disprove, though,
since that only takes one counter- example (which is why bad science
is often easier to recognize than non-science masking as science - the
latter is designed to be impervious to counter-examples.)
>>A handful of selected examples proves exactly nothing.
No they don't, but calling for proof by exhaustive testing is not the
rout to truth either.
But it is. It shows that the argument was made with an impossible
distribution, and so that it was wrong to be used as an argument in the
first place.
It's a theory. Just as the theory of gravity, and the theory of
relativity, there is a body of evidence in support of it. Whether
you consider that body sufficient or not is a different matter.
It appears you do not.
I do. And as a consequnce, I'll predict that any new browser-engine
that claims to support HTML and Javascript will also have a global
"window" property referencing the global object.
When I see a counter-example (or at least one that is not due to an
acknowledged bug), I'm ready to reevaluate the theory.
>Consider the widespread belief (and some would say "truth")) that the
speed of light is constant in a vacuum.
Apples, oranges.
No. Inductive reasoning - what you claimed wasn't sufficient to conclude
anything. And yet we do believe the theory of relativity. We act as if
it is the truth - although we do know that it is only our best attempt
yet at making a theory of how the world works, and it could be wrong.
>How significant that may be depends quite a bit on who is making the
report. [...]
No, that would be a fallacy (/ipse dixit/).
That way lies solipsism.
I cannot possibly test all the claims I hear. A lot of them I take
on "faith", because I trust the source (e.g., most of my education,
scientific papers in reviewed journals, etc.).
Most of such claims are not ones I would trust from anybody.
If my mother told you that 2^2203-1 is prime, would you trust her?
(There is no particular reason to, she's not an expert on primes, and
I wouldn't trust her to remember the number exactly).
If I give a link to http://primes.utm.edu/mersenne/ (which says
that 2^2203-1 is prime - in fact the 16th Mersenne prime), would
you trust that? I would - although I would probably try to find
one more reference, just to rule out a typo, since it's "just" a
web page. Had it been a journal paper, I would probably trust
it without further corroboration.
But it's the same information my mother gave. The only difference
is the source.
>That is an irrelevance. The question is whether the - global object <=>
window - relationship holds for all web browsers, not whether there is a
better alternative to using it.
No, the question was what would be the more reliable way to refer to the
Global Object,
I thought the question was on the way to access the "alert" function.
I wouldn't access it through a reference to the global object at all,
and instead just use "alert". Only if another variable might shadow
this global property would I care to use the global object. In that
case, I would probably just create my own local alert function:
function alert(string) {
this.alert(string);
}
and use that.
and I am still not convinced that this is `window' when the
standard since its first edition and all (non-broken) implementations in all
environments so far support `this' in the global context
Do you *know* that all browsers have non-broken implementations?
Or is that just moving the assumption back one step?
(or its less efficient and slightly less compatible equivalent of
using the `this' value as returned from an anonymous function).
It has the advantage of working even for code not running in the global
context, but is indeed a bit more cumbersome.
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Richard Cornford wrote:
>>That is only one of many meanings of "evidence", where others include
'support for a belief or induction'.
Belief belongs elsewhere, and induction does not apply here.
It does indeed belong. Inductive reasoning, using evidence to support a
theory, is the basis of science.
Yes, you have a theory, there is no doubt about it and no argument. The
problem with this theory of yours is that you are using it as basis for
design decisions and recommendations to others. As for science, inductive
reasoning is quite a different animal than you present it to be. Quote
<http://en.wikipedia.org/wiki/Inductive_reasoning>:
| Induction or inductive reasoning, sometimes called inductive logic, is the
| process of reasoning in which the premises of an argument are believed to
| support the conclusion but do not entail it; i.e. they do not ensure its
| truth.
| [...]
| A strong induction is thus an argument in which the truth of the premises
| would make the truth of the conclusion probable, but not definite.
| [...]
| In both of these examples of weak induction, the logical means of
| connecting the premise and conclusion (with the word "therefore") are
| faulty, and do not give us a strong inductively reasoned statement.
You should read this article and apply it to the discussed situation.
We are not talking mathematical induction, just as it's not mathematical
proofs we are after.
Logic does not require math; but it helps.
>>And the ability of "evidence" to "prove" anything has been strongly
disputed for a very long time now.
There are those who would disagree, most notably criminal
investigators. But it would appear you are playing the /advocatus
diaboli/ here.
I wouldn't think so.
"Evidence", as well as "proof", has different meaning in different
contexts. Three typical contexts are mathematics, the natural sciences,
and law.
The usage here is that of science. An accumulation of evidence does
indeed lead to an theory being accepted as valid.
But never more than a *theory*, despite your desperate trying to convince
everyone of the contrary.
>>How significant that may be depends quite a bit on who is making the
report. [...]
No, that would be a fallacy (/ipse dixit/).
That way lies solipsism.
Nonsense. Surely I can accept claims of others, no matter their reputation,
if reason and logic can show them to be true. It would then be best if the
people making the claims would be provide their reasoning along with their
claims, for the lack of it carries with it the possibility for the fallacy
of shifting the burden of proof ("show me that I am wrong, then I might
reconsider").
I cannot possibly test all the claims I hear.
You don't have to, in general. But you will have to if you were to use them
or advocate them, or this could rightfully be called blind leading the blind.
A lot of them I take on "faith", because I trust the source (e.g., most
of my education, scientific papers in reviewed journals, etc.). Most of
such claims are not ones I would trust from anybody.
There is the difference, the core of the issue. You take unproven (and
unprovable) statements for granted because you want to believe (in your view
of the world, the people making the statements). (A fascinating example of
how inductive reasoning tends to lead to questionable statements, and even
religion.) Where you rely on faith and wishful thinking, I rely on proof,
fact and logic. Since these ways to understanding are mutually exclusive,
and this has little to do with software development anyway, I suggest EOD.
BTW, your examples are only apples and oranges, too, which is why I will not
refer to them further. I suggest you try to understand that examples are
not everything, and that every comparison limps.
>>That is an irrelevance. The question is whether the - global object
<=window - relationship holds for all web browsers, not whether
there is a better alternative to using it.
>No, the question was what would be the more reliable way to refer to
the Global Object,
I thought the question was on the way to access the "alert" function.
That was the other question.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Thomas 'PointedEars' Lahn meinte:
No, the question was what would be the more reliable way to refer to the
Global Object
Sigh. No. The question was "alert()" vs. "window.alert()".
I was wrong: I wrote "...the global object, in browsers the window
object...". I should have written in "most browsers". Or "all browsers I
know of". Anyway, all I wanted to emphasize is, why "alert()" frequently
ends up at "window.alert()" and therefore is often seen in the wild.
Gregor
-- http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie http://web.gregorkofler.com ::: meine JS-Spielwiese http://www.image2d.com ::: Bildagentur für den alpinen Raum
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Lasse Reichstein Nielsen wrote:
>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>>Richard Cornford wrote:
That is only one of many meanings of "evidence", where others include
'support for a belief or induction'.
Belief belongs elsewhere, and induction does not apply here.
It does indeed belong. Inductive reasoning, using evidence to support a
theory, is the basis of science.
Yes, you have a theory, there is no doubt about it and no argument. The
problem with this theory of yours is that you are using it as basis for
design decisions and recommendations to others. As for science, inductive
reasoning is quite a different animal than you present it to be. Quote
<http://en.wikipedia.org/wiki/Inductive_reasoning>:
| Induction or inductive reasoning, sometimes called inductive logic, is the
| process of reasoning in which the premises of an argument are believed to
| support the conclusion but do not entail it; i.e. they do not ensure its
| truth.
| [...]
| A strong induction is thus an argument in which the truth of the premises
| would make the truth of the conclusion probable, but not definite.
| [...]
| In both of these examples of weak induction, the logical means of
| connecting the premise and conclusion (with the word "therefore") are
| faulty, and do not give us a strong inductively reasoned statement.
You should read this article and apply it to the discussed situation.
Any useful conclusion in these matters (that is, browser behaviour) is
always going to come down to inductive reasoning, since it's
impossible to know for certain the behaviour of all browsers - since
it's impossible to know you know about all browsers. We can only deal
with whatever browsers we know about. And even then, many of them can
reasonably be ignored.
Further more, inductive reasoning built upon observations of a large
enough set of browsers will probably be *more* useful than "pure
logic" extrapoling w3c standards or other any other set of primitives
that may not have any relation to reality, and you know it.
>We are not talking mathematical induction, just as it's not mathematical
proofs we are after.
Logic does not require math; but it helps.
But we're not dealing with pure logic either.
>>>And the ability of "evidence" to "prove" anything has been strongly
disputed for a very long time now.
There are those who would disagree, most notably criminal
investigators. But it would appear you are playing the /advocatus
diaboli/ here.
I wouldn't think so.
"Evidence", as well as "proof", has different meaning in different
contexts. Three typical contexts are mathematics, the natural sciences,
and law.
The usage here is that of science. An accumulation of evidence does
indeed lead to an theory being accepted as valid.
But never more than a *theory*, despite your desperate trying to convince
everyone of the contrary.
http://en.wikipedia.org/wiki/Theory:
"In science a theory is a testable model of the manner of interaction
of a set of natural phenomena, capable of predicting future
occurrences or observations of the same kind, and capable of being
tested through experiment or otherwise verified through empirical
observation. For the scientist, "theory" is not in any way an antonym
of "fact". For example, it is a fact that an apple dropped on earth
has been observed to fall towards the center of the planet, and the
theories commonly used to describe and explain this behavior are
Newton's theory of universal gravitation (see also gravitation), and
the general theory of relativity."
In other words (as the article mentions), we're not dealing with just
speculation or conjecture.
Sorry to bring that up, but your comment sounds a little too much like
the "just a theory" "excuse".
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Lasse Reichstein Nielsen wrote:
But never more than a *theory*, despite your desperate trying to convince
everyone of the contrary.
You say it's no more than a theory, as if that wasn't the highest goal
to aim for. http://www.notjustatheory.com/
(not the same subject matter, but the rebuttal of the "just a theory"
argument still holds).
Apart from that, I agree to EOD.
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Joost Diepenmaat wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Lasse Reichstein Nielsen wrote:
>>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Richard Cornford wrote:
That is only one of many meanings of "evidence", where others include
'support for a belief or induction'.
Belief belongs elsewhere, and induction does not apply here.
It does indeed belong. Inductive reasoning, using evidence to support a
theory, is the basis of science.
Yes, you have a theory, there is no doubt about it and no argument. The
problem with this theory of yours is that you are using it as basis for
design decisions and recommendations to others. As for science, inductive
reasoning is quite a different animal than you present it to be. Quote
<http://en.wikipedia.org/wiki/Inductive_reasoning>:
| Induction or inductive reasoning, sometimes called inductive logic, is the
| process of reasoning in which the premises of an argument are believed to
| support the conclusion but do not entail it; i.e. they do not ensure its
| truth.
| [...]
| A strong induction is thus an argument in which the truth of the premises
| would make the truth of the conclusion probable, but not definite.
| [...]
| In both of these examples of weak induction, the logical means of
| connecting the premise and conclusion (with the word "therefore") are
| faulty, and do not give us a strong inductively reasoned statement.
You should read this article and apply it to the discussed situation.
Any useful conclusion in these matters (that is, browser behaviour) is
always going to come down to inductive reasoning, since it's
impossible to know for certain the behaviour of all browsers -
No. Any useful conclusion would involve dismissing the premise, and to
accept that there is the probability of failure, although this can be
reduced with focusing on standards and proper feature-testing.
Sorry to bring that up, but your comment sounds a little too much like
the "just a theory" "excuse".
We are _not_ dealing with a scientific theory here.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Gregor Kofler wrote:
Thomas 'PointedEars' Lahn meinte:
>No, the question was what would be the more reliable way to refer to the
Global Object
Sigh. No. The question was "alert()" vs. "window.alert()".
The discussion lead elsewhere from that.
I was wrong: I wrote "...the global object, in browsers the window
object...". I should have written in "most browsers".
No.
Or "all browsers I know of".
Yes.
Anyway, all I wanted to emphasize is, why "alert()" frequently
ends up at "window.alert()" and therefore is often seen in the wild.
And I debated the validity of your explanation.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Joost Diepenmaat wrote:
>Any useful conclusion in these matters (that is, browser behaviour) is
always going to come down to inductive reasoning, since it's
impossible to know for certain the behaviour of all browsers -
No. Any useful conclusion would involve dismissing the premise, and to
accept that there is the probability of failure, although this can be
reduced with focusing on standards and proper feature-testing.
Feature-testing is useful but as you noted it does not give you any
guarantees. *nothing* you can do in javascript is going to give you
that. A useful conclusion is one that works right now in popular
browsers (however you define them), and minimizes browser-specific
"hacks".
Working according to the specs or whatever "theoretical" framework you
want is great, and should be done when it works (and works
efficiently), but it's not the goal.
I really don't know how else to approach browser scripting when the
most popular browser today doesn't even implement the ecmascript spec
correctly.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Joost Diepenmaat wrote:
>>Any useful conclusion in these matters (that is, browser behaviour) is
always going to come down to inductive reasoning, since it's
impossible to know for certain the behaviour of all browsers -
No. Any useful conclusion would involve dismissing the premise, and to
accept that there is the probability of failure, although this can be
reduced with focusing on standards and proper feature-testing.
Feature-testing is useful but as you noted it does not give you any
guarantees. *nothing* you can do in javascript is going to give you
that. A useful conclusion is one that works right now in popular
browsers (however you define them), and minimizes browser-specific
"hacks".
Guarantees do not enter into it. You should read more thoroughly what I write.
Working according to the specs or whatever "theoretical" framework you
want is great, and should be done when it works (and works
efficiently), but it's not the goal.
I don't remember anyone setting any goals here. But JFTR: I disagree.
I really don't know how else to approach browser scripting when the
most popular browser today doesn't even implement the ecmascript spec
correctly.
There is a difference between knowing that and why it can fail, and
believing that it cannot fail.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Joost Diepenmaat wrote:
>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>>Joost Diepenmaat wrote:
Any useful conclusion in these matters (that is, browser behaviour) is
always going to come down to inductive reasoning, since it's
impossible to know for certain the behaviour of all browsers -
No. Any useful conclusion would involve dismissing the premise, and to
accept that there is the probability of failure, although this can be
reduced with focusing on standards and proper feature-testing.
Feature-testing is useful but as you noted it does not give you any
guarantees. *nothing* you can do in javascript is going to give you
that. A useful conclusion is one that works right now in popular
browsers (however you define them), and minimizes browser-specific
"hacks".
Guarantees do not enter into it. You should read more thoroughly
what I write.
Likewise.
>Working according to the specs or whatever "theoretical" framework you
want is great, and should be done when it works (and works
efficiently), but it's not the goal.
I don't remember anyone setting any goals here. But JFTR: I disagree.
I didn't put that very clearly: *my* goal is to have javascript that
works correctly in as many useful browsers as possible with the least
amount of browser-specific code paths AND the least amount of feature
testing. I just want code that works and is easy to maintain (which
means I will use feature testing when useful). But I will not, for
example, test if the window object really refers to (something similar
enough to) the global object until I personally learn of a browser
that's actually used that doesn't have that feature or somehow breaks
my fairly browser-agnostic code. Stuff like that is easily fixed when
the actual issues arise. Javascript is IMHO just not the tool to use
if you want perpetual compatibility.
>I really don't know how else to approach browser scripting when the
most popular browser today doesn't even implement the ecmascript spec
correctly.
There is a difference between knowing that and why it can fail, and
believing that it cannot fail.
The browser model *can* fail everywhere. It's much more interesting to
me where it does right now.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/ This thread has been closed and replies have been disabled. Please start a new discussion. |
