[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 <[email protected]> wrote: > On Fri, Jun 17, 2011 at 4:52 PM, Allen Wirfs-Brock > <[email protected]>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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
