[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Fri Jun 17 18:00:00 PDT 2011

On Fri, Jun 17, 2011 at 4:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> Mark,
> I don't want to argue about the specific invarients you listed.  They
> generally make sense.  However I don't believe that they are as firmly
> embedded in the fabric of ES as your believe.
> Prior, to ES5 [...bunch of stuff about ES3...]

Hi Allen,

It sounds like you think I'm making a point about ES that spans at least ES3
and ES5. I'm not. I'm making a point only about ES5. ES3 was a mess and we
did an extraordinary job, starting under the ES3.1 banner and continuing
under the ES5 banner, of cleaning up that mess. So if we wish to speak
historically, my point spans ES3.1 to ES5.1.

> In ES5 we added [[DefineOwnProperty]] as an internal method and
> incorporated into it the attribute transtion rules you quoted.  However as
> an internal method it can have other "native" implementations that implement
> other rules.  I don't believe there is any contrary spec. language.

ES5.1 states the specification of all normal and abnormal native objects. I
didn't feel we needed spec language to state the invariants that all these
specific native specifications upheld, since they did uphold them.

>  We did put in the host object invarients but I don't believe we actually
> talked about expanding there applicability to all objects.
> I'm not saying it is necessarily a bad idea.  I just don't think it is
> implicit in ES5.

It is because I was careful to ensure, starting with our ES3.1
conversations, that all these specific native specs upheld these invariants.
I certainly admit that what these invariants were, and why they were
important, are all more clear to me now than they were then. I was
discovering the invariants that mattered by intuition while we were doing
the ES3.1 design.

We actually did better than I expected. In July 2009 when we wrote "Support
a statically verifiable, object-capability secure subset." into the Harmony
Goals at <http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals>, we
had already achieved this goal in ES5 and I didn't know it. I had been
groping towards this goal during the ES5 design hoping to make incremental
progress, but I didn't know we had crossed the finish line until December
2009 when I wrote the first SES prototype at <
Current development has moved to <

(David, the following should also serve as a partial answer to the question
of your's that I postponed)

As an example where I'm already exploiting these invariants: At <
you will find

   * Read the current value of base[name], and freeze that property as
   * a data property to ensure that all further reads of that same
   * property from that base produce the same value.
   * <p>The algorithms in startSES traverse the graph of primordials
   * multiple times. These algorithms rely on all these traversals
   * seeing the same graph. By freezing these as data properties the
   * first time they are read, we ensure that all traversals see the
   * same graph.
   * <p>The frozen property should preserve the enumerability of the
   * original property.
  function read(base, name) {
    var desc = Object.getOwnPropertyDescriptor(base, name);
    if (desc && 'value' in desc && !desc.writable && !desc.configurable) {
      return desc.value;

    var result = base[name];
    try {
      Object.defineProperty(base, name, {
        value: result, writable: false, configurable: false
    } catch (ex) {
      cantNeuter.push({base: base, name: name, err: ex});
    return result;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110617/00ffcb9c/attachment-0001.html>

More information about the es-discuss mailing list