JavaScript ECMAScript definitions

[Thomas 'PointedEars' Lahn]

[...] 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/d...script56/html/js56jsoriversioninformation.asp>


PointedEars

 

[Lasse Reichstein Nielsen]

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).

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

 

[Thomas 'PointedEars' Lahn]

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.

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".

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

 

[Richard Cornford]

Lasse Reichstein Nielsen wrote:

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.

 

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

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

 

[Lasse Reichstein Nielsen]

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

 

[Richard Cornford]

Richard Cornford wrote:

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.

 

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

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.