Initial ECMA formated ES5 draft available

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Tue Aug 25 13:52:29 PDT 2009


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.

Allen

>-----Original Message-----
>From: Jeff Walden [mailto:jwalden+es at MIT.EDU]
>Sent: Tuesday, August 25, 2009 12:32 PM
>To: Allen Wirfs-Brock
>Cc: es5-discuss at mozilla.org; es-discuss
>Subject: Re: Initial ECMA formated ES5 draft available
>
>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.
>
>Jeff



More information about the es-discuss mailing list