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 such context. 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? David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
