Some feedback on the July 4th ES3.1 draft
Robert Sayre
sayrer at gmail.com
Thu Jul 10 15:46:53 PDT 2008
As a general editorial comment, I find it difficult to follow the new
formalisms introduced, particularly in section 8.10.
--- 4.2.2 Voluntary Usage Language Subsets
This section is not acceptable to me. This is premature
standardization, and creates an unruly QA matrix. A very charitable
characterization :
| Full ES 3.x | ES 3.x + errors |
| ES 3.x - features | ES 3.x + errors - features |
This testing burden applies not only to ES implementors, but also to
library authors.
The claim that "usage subsets" do not create ES profiles is difficult
to take seriously. It seems to me that is exactly what they are for.
Some mealy conformance text doesn't change it, nor does the rhetorical
tactic of claiming the profile switch is "simply a way for the user of
the language to state their intent to voluntarily restrict themselves
so a well specified subset".
The section is does not contain a coherent rationale. It even claims
the language itself has recognized something:
"The ECMAScript Language recognizes the possibility that some users of
the language may wish to restrict their usage of some features
available in the language."
The "cautious" subset has no coherent rationale.
--- 4.3.29 Built-in Method
The term "built-in method" is rarely used, and should be removed. It
often appears as "standard built-in method Foo.bar.baz." This is not
necessary, since we are reading a standard and the methods are clearly
"built-in". Annex E refers to incompatible changes for "standard
built-in methods" in section 15 regarding extra arguments, but section
15 describes these requirements in terms of "functions".
--- 7.5.2 Keywords
The debugger keyword has been moved, but it is not used in the spec,
and there is no rationale.
--- 15.2.3 Properties of the Object Constructor
The new methods listed here do not have attributes listed, as
Object.prototype does. Is this intentional?
--- 15.4.4 Properties of the Array Prototype Object
Any divergence from the Array generics in Mozilla's implementation
should be considered a bug. I know a few have been raised already. It
would be much easier to check for divergence if an ES3.1
implementation existed in the open.
--- 15.5.4.20 String.prototype.trim ( )
ltrim() and rtrim() should be added.
--- 15.9.1.15 Date Time string format
"It also includes "date-times" which could be any combination of the above."
This is sloppy specification. I think I know what is intended, but
this sentence should be improved.
--- 15.9.5.43 Date.prototype.toISOString ( )
"All fields are present in the string."
This value should be defined as an RFC3339 timestamp in UTC, which
will reduce needless incompatibilities when these values make their
way onto the network.
--- 15.12 JSON
I'll send separate feedback on this section, but the July 4th draft
does not appear to match the most recent copy of json2.js. What's
going on here?
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
More information about the Es4-discuss
mailing list