Initial ECMA formated ES5 draft available
On Sat, Aug 22, 2009 at 2:00 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
The ES5 draft has now been reformatted to conform to current ECMA conventions. Somewhat uglier, IMHO, but it’s what we have to conform to.
This draft is available at the usual place es3.1:es3.1_proposal_working_draft
Allen, thanks for doing this. It's awesome to see this come together so well.
Things that have been recently discussed but which have resulted in no change. Issue deferred until next edition [...]
typeof operator and callable RegExps
On this issue, I do object. From discussions on the list, it seems we have
a clear consensus to change this to something more sensible. I agree it does make some sense for the committee to defer to editor's prerogative to some extent, especially considering the asymmetry of work undertaken. But given the direction we likely wish to take this in the future, the ES5 draft spec language here is, as previously discussed, likely worse than reverting this table to the ES3 spec language. Better is to have typeof "function" iff [[Class]] is "Function". This requires only the change to the table that Brendan asked someone to draft and which I have posted to the list.
If we can't agree on that, then let's please at least revert to the ES3 language or accept David-Sarah's proposed change. Any of these options are better than leaving the current ES5 language alone.
From: Mark S. Miller [mailto:erights at google.com]
Sent: Saturday, August 22, 2009 2:22 PM ... If we can't agree on that, then let's please at least revert to the ES3 language or accept David-Sarah's proposed change. Any of these options are better >than leaving the current ES5 language alone.
The only changes in the current draft in section 11.4.3 (typeof operator) from the ES3 language relate to host objects. As I read it, nothing related native objects is in anyway different between Es3 and ES5 in this sections.
ES3 "object": Object (native and doesn't implement [[Call]]) ES5 "object": Object (native and does not implement [[Call]]) ES3 "function": Object (native and implements [[Call]]) ES5 "function": Object (native or host and does implement [[Call]])
ES3 Implementation dependent: Object (host) ES5 Implementation-defined except may not be "undefined", "boolean", "number", or "string". : Object (host and does not implement [[Call]])
I don't think you want be to revert the host object related changes, do you?
On Sat, Aug 22, 2009 at 4:09 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
I don't think you want be to revert the host object related changes, do you?
Yes I do. That's exactly the issue. The important point is #2.c from: mail.mozilla.org/pipermail/es5-discuss/2009-August/003140.html.
On Sat, Aug 22, 2009 at 4:23 PM, Mark S. Miller <erights at google.com> wrote:
On Sat, Aug 22, 2009 at 4:09 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
I don't think you want be to revert the host object related changes, do you?
Yes I do. That's exactly the issue. The important point is #2.c from: mail.mozilla.org/pipermail/es5-discuss/2009-August/003140.html.
After a long discussion with Allen, in the interests of remaining done, I am dropping my objection. I expect typeof to remain a mess. Having failed to achieve consensus in a timely matter on how to fix it, I am now in favor of leaving it alone.
The really good news is that, as of ES5, [[Class]] testing does become reliable. Even in ES3R, [[Class]] testing is already pleasingly reliable. We should encourage code to switch from typeof testing to [[Class]] testing when practical.
When I view the formatted draft as a PDF file, the PDF index includes a lot of junk entries. I've attached a screenshot showing the index on the left. The highlighted index entry is at the top level of the index tree, but it is the first word of the paragraph on the right page after Table 21, to the left of the image of the mouse pointer. This looks like Word is deriving the index from formatting information and getting confused.
I hope we can clean this up. Especially for large documents like standards, the PDF index is extremely valuable; I certainly can't imagine using, say, the C++ '89 standard, without a proper index.
On 22.8.09 14:00 , Allen Wirfs-Brock wrote:
15.2.3.7 Object.defineProperties “atomic†processing clarified.
This still needs further clarification on how to address definition of properties on objects with custom [[DefineOwnProperty]] hooks, as earlier alluded to by David-Sarah Hopwood. I think a restriction on what custom definitions of [[DefineOwnProperty]] may do is in order, so that atomicity can actually be implemented; I'm not sure what that restriction should be, precisely. Simply saying [[DefineOwnProperty]] must not have side effects would directly contradict the JSClass.addProperty hook in SpiderMonkey by which property definitions may be "censored", such that the value that was set can be changed by the hook. I don't know whether this is a problem inherent to any DOM properties, but I would be surprised if it isn't. On the other hand, this hook supports arbitrary actions, which seem entirely out of the question as supportable. (I'm considering an ex post facto restriction that the only immediately observable side effect must be a modification of the property's value
as an immediate stopgap. This would allow observable side effects after Object.defineProperties returns, but I care about this only insofar as it makes partial rollback impossible to implement, and this invalidates as little previously-permissible hook behavior as possible.)
In any case, featureful implementations which in one form or another support modification of the effective behavior of [[DefineOwnProperty]] can't really implement Object.defineProperties as currently written, not without violating the atomicity requirement or making assumptions about potential custom behaviors.
I think there are underlying specification issues here that go beyond Object.defineProperties and we aren't going to be able to solve them for this edition. Historically, the ES specification have not defined precise contracts for the polymorphic internal methods and the ES5 spec. really hasn't improved things much in this regard except for a few invariants that were added in 8.6.2. I believe that there are many ways that "host objects" could "legally" implement the internal methods and still screw up the algorithms of the ES5 spec. Basically, it's up to an implementation to figure out how it is going to interface to external objects and how much of the ES semantics it can preserve in doing so.
Trying to improve this situation is a good thing to work on for the next edition, but I don't think additional special case "Band-Aids" are going to make things better now. I think the intent of Object.defineProperties is pretty clear. If somebody needs to design a host object [[DefineOwnProperty]] implementation or a ECMAScript extension that requires a custom [[DefineOwnProperty]] then they need to take the requirements of Object.defineProperties into account or simply decide to not conform to the specification.
It also screws up Word's internal on-screen navigation index. It must be some Word oddity because when I fix the overt symptom the problem returns after I save and reload. I'm working on it ...
Thanks, for pointing out that the problem shows up in the PDF. I agree that this makes it more serious.
The ES5 draft has now been reformatted to conform to current ECMA conventions. Somewhat uglier, IMHO, but it's what we have to conform to.
This draft is available at the usual place es3.1:es3.1_proposal_working_draft
There are undoubtedly some typographic bugs lurking after this massive conversion so please take a careful look at it as soon as possible. This probably a good time to consider looking at a printed copy. Also, reports of any technical bugs are still welcome but please hold feature additions/changes for the next edition.
My goal is to distribute to TC39 members in the first week of September the truly final document that we expect to approve at our Septembers meeting so any feedback on this draft really is needed as soon as possible.
Finally, here are the technical changes that have been incorporated into this version: 10.6 Arguments Object has reverted to having Object.prototype as its [[prototype]]. 15.2.3.7 Object.defineProperties "atomic" processing clarified. 15.4.4.14-15 Array.prototype.indexOf and lastIndexOf now use Strict Equality Comparison rather than SameValue algorithm 15.4.4.15-22 value of length property explicitly specified for each "Array extra" function. 15.12.3 JSON.stringify duplicate entries are filtered from the optional whitelist argument.
Things that have been recently discussed but which have resulted in no change. Issue deferred until next edition typeof operator and callable RegExps 15.9.1.8 Daylight Savings Time Adjustments