[Harmony Proxies] Proposal: Property fixing

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

[again with better formatting of the code. The previous one also looked good
when I sent it. If this one arrives looking crappy, please just follow the
link to the repository site. Email mangling of html befuddles me.]

On Fri, Jun 17, 2011 at 6:00 PM, Mark S. Miller <erights at google.com> wrote:

> 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 <
> http://code.google.com/p/es-lab/source/detail?r=3&path=/trunk/src/ses/initSES.js>.
> Current development has moved to <
> http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/
> >.
> (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 <
> http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#614>
> 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;
>   }
> --
>     Cheers,
>     --MarkM

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

More information about the es-discuss mailing list