JavaScript ECMAScript definitions

[Richard Cornford]

Re: JavaScript ECMAScript definitions

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue]
> 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.[/color]
<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]

Re: JavaScript ECMAScript definitions

Thomas 'PointedEars' Lahn wrote:
<snip>[color=blue]
> 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.[/color]

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.)
[color=blue]
> 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.[/color]
<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.