[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Sun Jun 19 09:44:20 PDT 2011

On Sat, Jun 18, 2011 at 4:44 PM, David Bruant <david.bruant at labri.fr> wrote:

> Le 19/06/2011 00:30, Mark S. Miller a écrit :
> > Hi David, yes, that code is just a stale illustrative example. This
> > abstraction itself is not being used, and the code predates many
> > changes to the proxy API that render it invalid. And even then, it was
> > sloppy in ways you point out, e.g, regarding enumerability.
> Sorry if i was a little harsh on my e-mail. It wasn't my intention.
> The critiques on the code were just meant to keep examples consistent to
> not puzzle newcomers to the wiki.

Hi David, I didn't take it as harsh, just explaining context. Critiques are
always appreciated. Tom, thanks for fixing the examples.

> > However, it is a good example of the kinds of abstraction that one
> > could write using the modern proxy API, *if* we don't weaken the
> > invariants it relies on. And again, the "read" function I pointed to
> > is a production example which also relies on these invariants.
> But the very question I am asking is: do we need this kind of
> abstractions? the "read" function you showed uses some invariants in
> production for SES. So these invariants should be kept (unless
> equivalent robustness can be guaranteed with weaker invariants).
> However, do all invariants have such use? I am sorry to ask this
> question this way, but this is all very new to me and I'm blind when it
> comes to justifying that such or such invariant is required to build
> such or such things which is used (or should be or may be) in such and
> such context.

Hi David,

The question you are asking is important I would like to take the time to
give it a serious answer. Unfortunately, I do not currently have that time
and a too-quick answer to this question, especially on es-discuss, will do
harm than good. I will get back to this, but not in the next two weeks.
(This isn't the only crucial es-discuss discussion I need to postpone. I'm
already feeling guilty about not engaging with the "can we do without
classes?" threads, but can't get to those soon either.)

That said, the short beginning of an answer is that these issues do not come
up primarily in the SES implementation, they come up primarily in
anticipated SES use, which will include code along the lines of the flawed
example Tom fixed. Safely handling objects from potential adversaries is
*hard*. The more useful invariants there are that such code might find
useful, that adversaries cannot violate, the easier this burden becomes.

There are other ways to approach the question of what such invariants should
be. E and Joe-E took a very different tack and ended up with a different
(and IMO better) mixture of what-is-easy and what-is-hard. Given the legacy
compatibility constraints shaping ES3.1, I think we ended up with about as
good a mix as could be expected. There are several things I wish we had
decided differently, but...

> By the way, I am a bit puzzled by the read function. The comment on top
> says "The frozen property should preserve the enumerability of the
> original property.". However, l.636-638, the call to defineProperty
> doesn't set "enumerable" (implicitly set to 'false'). Shouldn't it be
> enumerable:desc.enumerable, or am I missing something?

In an Object.defineProperty call to change an existing property, missing
attributes default to their current setting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110619/ad2721c2/attachment.html>

More information about the es-discuss mailing list