[Harmony Proxies] Proposal: Property fixing
david.bruant at labri.fr
Sat Jun 18 16:44:30 PDT 2011
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.
> 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
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?
More information about the es-discuss