469,929 Members | 1,789 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,929 developers. It's quick & easy.

JavaScript ECMAScript definitions

Hi all,

more or less just out of curiosity...

I had a short 'discussion' about JavaScript in different borwsers. The
other guy said that there's differeces in JavaScript accross browsers (I
assumed he meant apart from versions) "because there's different
functions".
I didn't agree because I think that's because of different DOM's. I know
that for example IE 5.0 (or 5.5?) does not support array.push() (and a
lot more), but isn't that just sloppy implementation or simply using
different versions of the language?

Is it safe to say that one version of JavaScript should be the same
everywhere except for DOM differences?

Is JavaScript ECMA-262 with browserspecific elements?

Thanks in advance,

Manno
Jul 23 '05 #1
31 1683


manno wrote:

I had a short 'discussion' about JavaScript in different borwsers. The
other guy said that there's differeces in JavaScript accross browsers (I
assumed he meant apart from versions) "because there's different
functions".
I didn't agree because I think that's because of different DOM's. I know
that for example IE 5.0 (or 5.5?) does not support array.push() (and a
lot more), but isn't that just sloppy implementation or simply using
different versions of the language?
Well, array.push is not part of the DOM at all, its a method of the core
object Array.

Is JavaScript ECMA-262 with browserspecific elements?


It depends on whom you ask and perhaps it also depends when you ask or
asked someone.
With its introduction in the Netscape 2.02 browser there was only one
implementation of the language and that was in a browser environment but
there was no ECMAScript standard at all. Later Netscape used its
JavaScript engine also on the server and documented both client-side
JavaScript and server-side JavaScript "versions" which consisted of core
objects specified in ECMAScript and host environment specific objects
like window, document in client-side JavaScript and server specific
objects in server-side JavaScript.
By now Netscape respectively Mozilla has two open-source JavaScript
engines, one called Spidermonkey implemented in C, the other called
Rhino imlemented in Java, and there are many different applications that
use those engines. So you can have JavaScript scripting in many
environments, not only browser specific ones.
And the MS JScript scripting engine can also be embedded in many
different environments, in the IE browser but as well in ASP pages as in
Windows Script host.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 23 '05 #2
Martin Honnen wrote:
Well, array.push is not part of the DOM at all, its a method of the core
object Array.
I know the array object's functions are no part of any DOM, I was trying
to go along in the arguments of the guy I argued with. But to go
_against_ his argument, is it sloppy implementation or just another
version of JavaScript that IE 5 version uses?
So you can have JavaScript scripting in many
environments, not only browser specific ones.


That was more or less why I asked, Flash (and the new Director MX 2004)
support "ECMAScript-compliant JavaScript syntax", I was wondering if
this actually could be said of browsers too: "Firefox supports
ECMAScript-compliant JavaScript syntax".

All with a different 'DOM' ofcourse.

Thanks
Manno
Jul 23 '05 #3


manno wrote:
Martin Honnen wrote:
Well, array.push is not part of the DOM at all, its a method of the
core object Array.

I know the array object's functions are no part of any DOM, I was trying
to go along in the arguments of the guy I argued with. But to go
_against_ his argument, is it sloppy implementation or just another
version of JavaScript that IE 5 version uses?


MS calls its implementation of JavaScript/ECMAScript JScript. I think
IE5 came with JScript 5 and whether at that time ECMAScript edition 3
was already out I don't remember exactly, I think Windows 98 already
featured IE5 while the ECMAScript edition 3 standard came out at the end
of 1999 thus MS was probably not sloppy in implementing that standard
but rather focussing on other things and waiting for ECMAScript edition
3 to be finalized.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 23 '05 #4
manno <ma***@xs4all.nl> writes:
I know the array object's functions are no part of any DOM, I was
trying to go along in the arguments of the guy I argued with. But to
go _against_ his argument, is it sloppy implementation or just another
version of JavaScript that IE 5 version uses?
It's JScript, not Javascript. There is no standard for Javascript
(except perhaps Netscape's documentation for JavaScript).
What there is, is ECMAScript, as specified by ECMA 262. It is currently
at version 3. Array.prototype.push was not in ECMA 262 v2, but is in
v3. It is likely that the versions of JScript shipped with IE 5 was
based on ECMA 262 v2.
That was more or less why I asked, Flash (and the new Director MX
2004) support "ECMAScript-compliant JavaScript syntax", I was
wondering if this actually could be said of browsers too: "Firefox
supports ECMAScript-compliant JavaScript syntax".


Sure. And it is just a way of saying "supports ECMAScript" that still
makes sense for people who think it's all called Javascript.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #5
JRS: In article <40********@olaf.komtel.net>, seen in
news:comp.lang.javascript, Martin Honnen <ma*******@yahoo.de> posted at
Fri, 23 Apr 2004 16:39:21 :

MS calls its implementation of JavaScript/ECMAScript JScript. I think
IE5 came with JScript 5 and whether at that time ECMAScript edition 3
was already out I don't remember exactly, I think Windows 98 already
featured IE5 while the ECMAScript edition 3 standard came out at the end
of 1999 thus MS was probably not sloppy in implementing that standard
but rather focussing on other things and waiting for ECMAScript edition
3 to be finalized.


Windows 98 was released in the UK (on 1998-07-01, IIRC) with MSIE 4
4.72.3110 SP1 using JScript 3.1.2124 or so it seems.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #6
Lasse Reichstein Nielsen wrote:

Thanks both for enlightning stuff a bit. I realise reading my questions
that I may not have been really clear.

About the JScript in IE. I was aware of JScript, but thought it was
totally seperate from JavaScript (never bothered to look at it except
for minimal serverside scripting).
But if IE calls it JScript and doesn't run JavaScript, what happens with
the type and language attribute of the script tag if set to
"text/JavaScript" and "JavaScript{version}"?

Manno
Jul 23 '05 #7
manno <ma***@xs4all.nl> wrote in message news:<40*********************@news.xs4all.nl>...
Hi all,

more or less just out of curiosity...

I had a short 'discussion' about JavaScript in different borwsers. The
other guy said that there's differeces in JavaScript accross browsers (I
assumed he meant apart from versions) "because there's different
functions".
I didn't agree because I think that's because of different DOM's. I know
that for example IE 5.0 (or 5.5?) does not support array.push() (and a
lot more), but isn't that just sloppy implementation or simply using
different versions of the language?

Is it safe to say that one version of JavaScript should be the same
everywhere except for DOM differences?

Is JavaScript ECMA-262 with browserspecific elements?

Thanks in advance,

Manno


IE 5.5+ supports array.push(), IE Mac does not.
Jul 23 '05 #8


Dr John Stockton wrote:
JRS: In article <40********@olaf.komtel.net>, seen in
news:comp.lang.javascript, Martin Honnen <ma*******@yahoo.de> posted at
Fri, 23 Apr 2004 16:39:21 :
MS calls its implementation of JavaScript/ECMAScript JScript. I think
IE5 came with JScript 5 and whether at that time ECMAScript edition 3
was already out I don't remember exactly, I think Windows 98 already
featured IE5 while the ECMAScript edition 3 standard came out at the end
of 1999 thus MS was probably not sloppy in implementing that standard
but rather focussing on other things and waiting for ECMAScript edition
3 to be finalized.

Windows 98 was released in the UK (on 1998-07-01, IIRC) with MSIE 4
4.72.3110 SP1 using JScript 3.1.2124 or so it seems.


Somehow I still associate some IE5 release with some Windows 98 release,
I think there is also Windows 98 second edition (Windows 98 2 ED), maybe
that came with IE5 and was still out before the ECMAScript edition 3
specification.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 23 '05 #9
manno wrote:
About the JScript in IE. I was aware of JScript, but thought it was
totally seperate from JavaScript [...]
It is. Nevertheless both JavaScript and JScript are ECMAScript
implementations (actually, JScript claims to be one while JavaScript is
one), so they share common objects and methods. However, since objects and
methods may be (and actually are) implemented differently. ECMAScript is a
language to be implemented and the language specification makes clear where
a conforming implementation has certain liberties.
But if IE calls it JScript and doesn't run JavaScript, what happens with
the type and language attribute of the script tag if set to
"text/JavaScript" and "JavaScript{version}"?


It executes it anyway, using an engine that supports both JScript and VBScript.
PointedEars
Jul 23 '05 #10
On Mon, 03 May 2004 05:35:07 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
manno wrote:
About the JScript in IE. I was aware of JScript, but thought it was
totally seperate from JavaScript [...]
It is. Nevertheless both JavaScript and JScript are ECMAScript
implementations (actually, JScript claims to be one while JavaScript is
one),


Sorry, why do you claim a distinction, the number of non-conformance
to the specs is minimal in both implementations, but both
implementations have them. JavaScript is certainly not a conformant
implementation any more than JScript is.
It executes it anyway, using an engine that supports both JScript and VBScript.


The core Script Engine doesn't support both JScript and VBScript,
there's a host engine which supports any ActiveScripting language, and
there's seperate implementations of JScript and VBScript - delete
vbscript.dll from your windows box and JScript still works fine.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #11
Jim Ley wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:
manno wrote:
About the JScript in IE. I was aware of JScript, but thought it was
totally seperate from JavaScript [...]


It is. Nevertheless both JavaScript and JScript are ECMAScript
implementations (actually, JScript claims to be one while JavaScript is
one),


Sorry, why do you claim a distinction, the number of non-conformance to
the specs is minimal in both implementations, but both implementations
have them. JavaScript is certainly not a conformant implementation any
more than JScript is.


Two obvious reasons: For example, I know of versions of JScript which yield
a script error even if one only tests *if* a property exists. In JScript,
only a function statement with mandatory identifier is specified; the
"function" operator (allowing for anonymous functions) as defined in
JavaScript, works anyway. I do not know of similar flaws in JavaScript.
It executes it anyway, using an engine that supports both JScript and
VBScript.


The core Script Engine doesn't support both JScript and VBScript, there's
a host engine which supports any ActiveScripting language, and there's
seperate implementations of JScript and VBScript - delete vbscript.dll
from your windows box and JScript still works fine.


ACK, thanks.
PointedEars
Jul 23 '05 #12
On Mon, 03 May 2004 21:49:13 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Jim Ley wrote:
Two obvious reasons: For example, I know of versions of JScript which yield
a script error even if one only tests *if* a property exists.
Sure, but I know of the same in SpiderMonkey impls.
In JScript,
only a function statement with mandatory identifier is specified; the
"function" operator (allowing for anonymous functions) as defined in
JavaScript, works anyway.
Sorry, I'm missing what you're trying to say here? it's something
defined in _JavaScript_ that you're saying isn't in JScript and that's
a reason to say JScript isn't ECMAScript conformant?
I do not know of similar flaws in JavaScript.


Just yesterday there was a discussion on the non-conformance of \b in
RegExps - it was agreed it was a positive non-conformance, but it's
still not conformant. There are also others.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #13
Jim Ley wrote:
Thomas 'PointedEars' Lahn wrote:
Jim Ley wrote: Two obvious reasons: For example, I know of versions of
JScript which yield a script error even if one only tests *if* a
property exists.


Sure, but I know of the same in SpiderMonkey impls.


And that is a *serious* violation of the ECMAScript specification.
Tests must be possible, even if they are unsuccessful at last.
In JScript, only a function statement with mandatory identifier is
specified; the "function" operator (allowing for anonymous functions)
as defined in JavaScript, works anyway.


Sorry, I'm missing what you're trying to say here? it's something
defined in _JavaScript_ that you're saying isn't in JScript and that's a
reason to say JScript isn't ECMAScript conformant?


No anonymous functions with "function" keyword and without identifier
are specified in ECMAScript. JavaScript calls this a "function"
operator. JScript does not specify this at all, yet it works.
PointedEars
Jul 23 '05 #14
Thomas 'PointedEars' Lahn wrote:
Jim Ley wrote:
Thomas 'PointedEars' Lahn wrote:
Jim Ley wrote: Two obvious reasons: For example, I know of versions of
JScript which yield a script error even if one only tests *if* a
property exists.


Sure, but I know of the same in SpiderMonkey impls.

And that is a *serious* violation of the ECMAScript specification.


ECMA is a recommendation and nothing more. It reminds me of the W3C.
Yes, its nice to "comply", but it is not *required*. I would rather
write/produce code that *works* than code that *complies* but doesn't work.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jul 23 '05 #15
On Mon, 03 May 2004 17:49:58 -0400, Randy Webb
<hi************@aol.com> wrote:
Thomas 'PointedEars' Lahn wrote:
Jim Ley wrote:
Thomas 'PointedEars' Lahn wrote:

Jim Ley wrote: Two obvious reasons: For example, I know of versions of
JScript which yield a script error even if one only tests *if* a
property exists.

Sure, but I know of the same in SpiderMonkey impls.

And that is a *serious* violation of the ECMAScript specification.


Well sure, PIE isn't conformant - hardly news there. (the error also
only manifests itself with host objects, so it's hardly deadly in the
real world, and it doesn't happen on real browsers.)
ECMA is a recommendation and nothing more. It reminds me of the W3C.


No, unlike the W3C stuff, ECMAScript is a proper International
standard. again there's good reasons for not worrying about \b in
regexps or \ at the end of line or the other minor non-conformances
though, and the various ES impl's are very much more conformant than
anything else we get to play with.

(I still don't understand Thomas's point about function literals, all
I can see is a complaint against JScript's documentation since "it
works".

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #16
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
No anonymous functions with "function" keyword and without identifier
are specified in ECMAScript. JavaScript calls this a "function"
operator. JScript does not specify this at all, yet it works.


You are distinguishing between the documentation of JScript and the
actual implementation. The implementation is ECMAScript conformant.
The documentation is flawed.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #17
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
No anonymous functions with "function" keyword and without identifier
are specified in ECMAScript. JavaScript calls this a "function"
operator. JScript does not specify this at all, yet it works.
You are distinguishing between the documentation of JScript and the
actual implementation.


Yes, I do.
The implementation is ECMAScript conformant.
It is not, but the point is not the documentation issue but, for example,
the property test issue. I am yet too see something specified that badly
b0rken in JavaScript.
The documentation is flawed.


Additionally, since it omits important features like this but ibid
it is stated that JScript is an ECMAScript conforming implementation.
PointedEars
Jul 23 '05 #18
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Lasse Reichstein Nielsen wrote:
The implementation is ECMAScript conformant.


It is not, but the point is not the documentation issue but, for example,
the property test issue. I am yet too see something specified that badly
b0rken in JavaScript.


Which test is that? If it is on a host object, then there is no
guarantee that it should work.
The documentation is flawed.


Additionally, since it omits important features like this but ibid
it is stated that JScript is an ECMAScript conforming implementation.


Well, what's the problem then? That says that function expressions
work, even if it is not explicitly mentioned anywhere else in the
JScript documentation. :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #19
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Lasse Reichstein Nielsen wrote:
The implementation is ECMAScript conformant. It is not, but the point is not the documentation issue but, for example,
the property test issue. I am yet too see something specified that badly
b0rken in JavaScript.


Which test is that?


I have never experienced such a behavior, only read of it (the
discussion was about the problems of a generic DHTML library):

,-<bv************@ID-3551.news.uni-berlin.de>
|
| [...]
| Rette mal bei IE4 auf dem Mac blind eine existierende Fenstereigenschaft,
| der nicht zuvor ein Wert zugewiesen wurde. Dein Rettungsversuch endet mit
| einer fehlermeldung. Du kannst auch nicht prüfen, ob es etwas zu retten
| gibt. Allein die Prüfung verursacht schon einen fehler, wenn es nichts zu
| retten gibt. Bei einem normalen Browser würdest Du einen eventiellen
| error-Handler retten, Deinen eigenen konnektieren und dann innerhalb
| Deines eigenen den geretteten aufrufen. Bei IE4 auf dem Mac geht das
| nicht, wenn es nicht schon einen error-Handler gibt. Genau das aber kannst
| Du nicht feststellen, ohne einen Fehler zu riskieren. Bugs dieser Art gibt
| es massenhaft. [...]

Translation:

| [...]
| With IE4 on the Mac, try to make a backup of an existing property of [a]
| window that has not been assigned a value previously. Your trial results
| in an error message. You cannot even check if there is something to back
| up. The check itself results in an error if there is nothing to back up.
| In a normal browser you would back up a possible error handler, connect
| your own and then call the backed up one from yours. With IE4 on the
| Mac this is impossible if there is not already an error handler. But
| you cannot determine exactly this without risking an error. There are
| a lot of bugs like this. [...]
If it is on a host object, then there is no guarantee that it should work.


Wrong. Even host objects, if they provide an ECMAScript interface, need to
exhibit ECMAScript compliant behavior. That is, for example, the mere test
for a property must not result in a runtime error.
PointedEars
Jul 23 '05 #20
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Translation:

| [...]
| With IE4 on the Mac,
(I am not sure what "an existing property ... that has not been
assigne a value previously" is ... how do we know it exists if
we haven't created it, and can't read it?).

It's highly probable that a browser released in January 1998 doesn't
implement ECMAScript v3, which was finalized in December 1999.
In the same way, Netscape's JavaScript 1.2 wasn't ECMAScript compliant
either.

However, current versions of JavaScript and JScript are on the same
level of ECMAScript conformance - almost perfect.

Wrong. Even host objects, if they provide an ECMAScript interface, need to
exhibit ECMAScript compliant behavior. That is, for example, the mere test
for a property must not result in a runtime error.


No. ECMA 262 v3, section 8.6.2 says:
---
Host objects may implement these internal methods with any
implementation-dependent behaviour, or it may be that a host object
implements only some internal methods and not others.
---
where "these internal methods" includes [[Get]]. If [[Get]] is undefined,
then merely testing for a property will give a runtime error.

With host objects, all bets are off.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #21
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Translation:
| [...]
| With IE4 on the Mac,
(I am not sure what "an existing property ... that has not been assigne a
value previously" is ... how do we know it exists if we haven't created
it, and can't read it?).


We can write to it and see an effect, I suppose.
It's highly probable that a browser released in January 1998 doesn't
implement ECMAScript v3, which was finalized in December 1999. In the
same way, Netscape's JavaScript 1.2 wasn't ECMAScript compliant either.
IE for Mac is using JScript which has always claimed to be ECMAScript compliant.
However, current versions of JavaScript and JScript are on the same level
of ECMAScript conformance - almost perfect.
Well, I had wo workaround the same b0rken behavior with host objects in the
current IE (JScript 5.6.x).
Wrong. Even host objects, if they provide an ECMAScript interface,
need to exhibit ECMAScript compliant behavior. That is, for example,
the mere test for a property must not result in a runtime error.


[...] If [[Get]] is undefined, then merely testing for a property will
give a runtime error.


Not necessarily. AIUI the "typeof" operator does not call [[Get]] always:

| 8.7 The Reference Type
| [...]
| GetBase(V). Returns the base object component of the reference V.
| GetPropertyName(V). Returns the property name component of the
| reference V.

| 11.4.3 The typeof Operator
|
| The production UnaryExpression : typeof UnaryExpression is evaluated as
| follows:
|
| 1. Evaluate UnaryExpression.
| 2. If Type(Result(1)) is not Reference, go to step 4.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| 3. If GetBase(Result(1)) is null, return "undefined".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| 4. Call GetValue(Result(1)).
^^^^^^^^^^^^^^^^^^^^^^^^
| 5. Return a string determined by Type(Result(4)) according to the
| following table:
| [...]

| 8.7.1 GetValue (V)
|
| 1. If Type(V) is not Reference, return V.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| 2. Call GetBase(V).
| 3. If Result(2) is null, throw a ReferenceError exception.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| 5. Return Result(4).

But that operator is available since the first version of JScript:
With host objects, all bets are off.


No, they are not, at least they *should not*.
PointedEars
Jul 23 '05 #22
Thomas 'Ingrid' Lahn wrote:
Lasse Reichstein Nielsen wrote:
[...] If [[Get]] is undefined, then merely testing for a property will
give a runtime error.


Not necessarily. AIUI the "typeof" operator does not call [[Get]] always:
[...]
But that operator is available since the first version of JScript:


<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsoriversioninformation.asp>
PointedEars
Jul 23 '05 #23
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
(I am not sure what "an existing property ... that has not been assigne a
value previously" is ... how do we know it exists if we haven't created
it, and can't read it?).
We can write to it and see an effect, I suppose.


You can also write to a nonexisting property. That alone doesn't
distinguish an existing property that has not been assigned a value
from a nonexisting property.

(I.e., I still haven't understood the actual problem).
It's highly probable that a browser released in January 1998 doesn't
implement ECMAScript v3, which was finalized in December 1999. In the
same way, Netscape's JavaScript 1.2 wasn't ECMAScript compliant either.


IE for Mac is using JScript which has always claimed to be
ECMAScript compliant.


Which version of ECMAScript? IE 4/Mac will will probably be v2
compliant.
[...] If [[Get]] is undefined, then merely testing for a property will
give a runtime error.


Not necessarily. AIUI the "typeof" operator does not call [[Get]] always:


Yes, it won't need to use the [[Get]] method if
1) the value isn't a reference to a property, or
2) the reference has a base object that is null.

I highly doubt such a reference can be created programmatically,
without resorting to host objects. In any case, it will use [[Get]]
if it tries to test for a property of an actual object.
No, they are not, at least they *should not*.


I agree that they shouldn't be, but alas, the standard says they are.

You can not rely on *any* feature of a host object. It is valid
ECMAScript to have a host object with *no* internal properties,
including [[Get]]. It will fail in pretty much any expression you use
it in, but it's a valid ECMAScript host object.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #24
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
(I am not sure what "an existing property ... that has not been assigne a
value previously" is ... how do we know it exists if we haven't created
it, and can't read it?). We can write to it and see an effect, I suppose.


You can also write to a nonexisting property. That alone doesn't
distinguish an existing property that has not been assigned a value
from a nonexisting property.


Correct.
(I.e., I still haven't understood the actual problem).
Yes, indeed. You asked "how do we know it exists if we haven't
created it, and can't read it?" and that was my reply.
It's highly probable that a browser released in January 1998 doesn't
implement ECMAScript v3, which was finalized in December 1999. In the
same way, Netscape's JavaScript 1.2 wasn't ECMAScript compliant either.

IE for Mac is using JScript which has always claimed to be
ECMAScript compliant.


Which version of ECMAScript? IE 4/Mac will will probably be v2
compliant.


So?
[...] If [[Get]] is undefined, then merely testing for a property will
give a runtime error.


Not necessarily. AIUI the "typeof" operator does not call [[Get]] always:


Yes, it won't need to use the [[Get]] method if
1) the value isn't a reference to a property, or


That's exactly the point.
2) the reference has a base object that is null.

I highly doubt such a reference can be created programmatically,
Well, it can. The mere "typeof" test for a property must not result in a
script error if that property does not exist since [[Get]] is not called
and no other object-dependent methods are involved. But it *does* in the
mentioned versions of IE and JScript, and it certainly does with certain
recent IE host objects (which is why I had to exclude the test for certain
properties in my ObjectInspector, to get it straight).
without resorting to host objects.
I do not know for sure, need to check my code first.
In any case, it will use [[Get]] if it tries to test for a property of
an actual object.
Of course. But it must not trigger an error if the property
does not exist and we test for the property with "typeof".
No, they are not, at least they *should not*.


I agree that they shouldn't be, but alas, the standard says they are.


They are not.
You can not rely on *any* feature of a host object. It is valid
ECMAScript to have a host object with *no* internal properties,
including [[Get]]. It will fail in pretty much any expression you use
it in, but it's a valid ECMAScript host object.


No. If I test for properties with "typeof" and this property does not
exist, an ECMAScript compliant object/implementation would not trigger
a script error.
PointedEars
Jul 23 '05 #25
Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> writes:
In any case, it will use [[Get]] if it tries to test for a property of
an actual object.
Of course. But it must not trigger an error if the property
does not exist and we test for the property with "typeof".
Yes it must, by the specification of typeof.

If the argument to typeof, call it V, is a Reference Type
(q.v. section 8.7), where the value of GetBase(V) is a non-null host
object, GetPropertyName(V) is "foo", and where the [[Get]] property of
that host object throws an exception when called with the argument
"foo", then it will fail.

The sequence of execution is:

In step 4 of the typeof operator, it will call getValue on the
paramter. In step 4 of getValue, the [[Get]] function is called
on the host object, throwing an exception.
(I did say that host objects didn't need to implement [[Get]]. That's
not true. The [[Get]] method can, however, act "in any manner").

No. If I test for properties with "typeof" and this property does not
exist, an ECMAScript compliant object/implementation would not trigger
a script error.


For host objects, the object decides what "does not exist" means. It can
implement [[Get]] and [[HasProperty]] inconsistently (failing on [[Get]]
but returning true on [[HasProperty]] for the same property name).

The typeof operator use getValue, which uses [[Get]], which can be made
to fail for a host object. It would be stupid, but it's valid.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #26
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:

<snip>
You can not rely on *any* feature of a host object. It is valid
ECMAScript to have a host object with *no* internal properties,
including [[Get]]. It will fail in pretty much any expression you use
it in, but it's a valid ECMAScript host object.


No. If I test for properties with "typeof" and this property does not
exist, an ECMAScript compliant object/implementation would not trigger
a script error.


When a typeof test generates an error while reading a property of a host
object it seems unlikely that the property does not exist. I would
conclude that a typeof test on a named property of a host object that
generates an error (or crashes the browser) indicated that the property
did refer to something, but that the something referred to was
sufficiently unusual that attempting to use it caused problems.

But Mozilla suffers from this pro0blem as much as IE does (and most over
browsers); Try examining the properties of the global JavaClass and
JavaPackage objects.

Richard.
Jul 23 '05 #27
Lasse Reichstein Nielsen wrote:
The typeof operator use getValue, which uses [[Get]],
But not *always* which is the point you still do not seem to see.
which can be made to fail for a host object. It would be stupid, but
it's valid.


1. In section 5.2:

Result(n) is *not* an implementation/object dependent method:
"The notation Result(n) is used as shorthand for 'the result
of step n'."

Type() is *not* an implementation/object dependent method:
"Type(x) is used as shorthand for 'the type of x'".

2. In section 8.7:
"A Reference is a reference to a property of an object.
A Reference consists of two components, the base object
and the property name."

3. In section 11.4.3 (on how the "typeof" operation is evaluated):
"1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, go to step 4."

That would apply to a property that does not exist.

4. Ibid: "4. Call GetValue(Result(1))."

5. In GetValue() which is *not* an implementation/object
dependent method:
"1. If Type(V) is not Reference, return V."

6. In section 5.2:
"When an algorithm is to produce a value as a result, the
directive 'return x' is used to indicate that the result
of the algorithm is the value of x and that the algorithm
should terminate."
^^^^^^^^^
7. So [[Get]] (step 4 in GetValue()) should *not* be called
if the operand is not of type Reference (i.e. there is
no such method) if the implementation is an ECMAScript 3
conforming one.

But "typeof" triggers a script error *anyway* with certain
host objects in JScript and that is clearly a bug (i.e.
*non-conforming* behavior of the implementation).

See?
PointedEars
Jul 23 '05 #28
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote: <snip>
You can not rely on *any* feature of a host object. It is valid
ECMAScript to have a host object with *no* internal properties,
including [[Get]]. It will fail in pretty much any expression you use
it in, but it's a valid ECMAScript host object.


No. If I test for properties with "typeof" and this property does not
exist, an ECMAScript compliant object/implementation would not trigger
a script error.


When a typeof test generates an error while reading a property of a host
object it seems unlikely that the property does not exist.


But yet such *tests* are highly likely since one seldom
knows the host environment the script code runs in.
I would conclude that a typeof test on a named property of a host object
that generates an error (or crashes the browser) indicated that the
property did refer to something, but that the something referred to was
sufficiently unusual that attempting to use it caused problems.
IBTD. It is not up to the implementator to decide what accesses
by the programmer are likely and thus must be guarded and which
are not. An implementation needs to work, in all situations that
can be conceived, otherwise it is useless.
But Mozilla suffers from this pro0blem as much as IE does (and most over
browsers); Try examining the properties of the global JavaClass and
JavaPackage objects.


Alas, that's true, I have already had a hard time
to workaround that and I am still not done.
PointedEars
Jul 23 '05 #29
Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> writes:
2. In section 8.7:
"A Reference is a reference to a property of an object.
A Reference consists of two components, the base object
and the property name."

3. In section 11.4.3 (on how the "typeof" operation is evaluated):
"1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, go to step 4."

That would apply to a property that does not exist.


No. A property access on an object to a property that doesn't exist
would *still* be a Reference, with a base object and a property
name. It's just that that base object doesn't have a property by that
name. The result is still a Reference.

The expression "foo.bar" (or the equivalent "foo['bar']"), where "foo"
refers to an object, and "bar" is not the name of a property of that
object, evaluates to a reference according to section 11.2.1.
In particular, it is the productions:
MemberExpression.identifier
MemberExpression[<identifier-string>Expression]
where Expression is <identifier-string>.

The evaluation of this is:
1. Evaluate MemberExpression.

Here MemeberExpression is a PrimaryExpression, which is an identifier.
The identifier is evaluated according to section 10.1.4. In this case
it gives a Reference to the object referenced by "foo".

2. Call GetValue(Result(1)).

Convert the Reference to a value. It is an object.

3. Evaluate Expression.

The expression "'bar'" is a literal and evaluates to the String 'bar'.

4. Call GetValue(Result(3)).

Just 'bar' again, since it is not a Refererence.

5. Call ToObject(Result(2)).

Result(2) is already an object, so just the same object again.

6. Call ToString(Result(4)).

Result(4) is already a string, so just the same string again.

7. Return a value of type Reference whose base object is Result(5) and
whose property name is Result(6).

That is, a Reference with base object being the object referenced
by the variable "foo", and property name "bar", even if there is
no property called "bar" on "foo"!

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #30
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote: <snip> IBTD. It is not up to the implementator to decide what accesses
by the programmer are likely and thus must be guarded and which
are not. An implementation needs to work, in all situations that
can be conceived, otherwise it is useless.

<snip>

Because this problem seems to inflict every web browser, to a greater or
lesser extent, you are effectively dismissing them all as useless. That
is fine, but unhelpful as we still have to script them. Though it seems
extreme as many people seem to get a lot of use out of their browsers.

In most of the cases I have seen of browsers that implement host objects
that are unfriendly when attempts are made to interact with them using
scripts, those objects are peripheral to normal browser scripting, often
undocumented and, if not, their use can be avoided. So knowing that
attempting to verify the - appendChild - method of an attribute Node on
some IE 6 versions will crash the browser is interesting, but
unimportant, as using that method in that context is unnecessary (as
attribute creation and manipulation is facilitated by other means).

On the whole I think it would be better if the browser implementers did
not expose objects that they do not expect to be scripted to javascript,
but they do so some responsibility should rest with the script authors
not to set about undocumented and unexpected interactions.

Yes this sort of thing is a problem when trying to create comprehensive
cross-browser object inspectors, but that task is somewhat specialised.

Richard.
Jul 23 '05 #31
Thomas 'PointedEars' Lahn wrote:
<snip>
3. In section 11.4.3 (on how the "typeof" operation is evaluated):
"1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, go to step 4."

That would apply to a property that does not exist.
I think you are miss-interpreting here (maybe). If the expression was:-

typeof "a_string"

- or -

typeof 6

- then the result of step 1 would not be a Reference type, but if the
UnaryExpression was a property accessor, or an unqualified identifier,
then the result of evaluating it will always be a Reference type.
(Assuming no exception is thrown while evaluating the property
accessor.)
4. Ibid: "4. Call GetValue(Result(1))."

5. In GetValue() which is *not* an implementation/object
dependent method:
"1. If Type(V) is not Reference, return V."

6. In section 5.2:
"When an algorithm is to produce a value as a result, the
directive 'return x' is used to indicate that the result
of the algorithm is the value of x and that the algorithm
should terminate."
^^^^^^^^^
7. So [[Get]] (step 4 in GetValue()) should *not* be called
if the operand is not of type Reference (i.e. there is
no such method) if the implementation is an ECMAScript 3
conforming one.

<snip>

But as a property accessor will always evaluate as a Reference type (if
it does not error itself first) the [[Get]] method will be called.

Richard.
Jul 23 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Philip | last post: by
7 posts views Thread by Wm.M.Thompson | last post: by
25 posts views Thread by Peter Michaux | last post: by
34 posts views Thread by dhtml | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.