Le 10/04/2011 23:27, Dmitry A. Soshnikov a écrit : > On 11.04.2011 18:07, Mark S. Miller wrote: >> On Sun, Apr 10, 2011 at 11:21 PM, David Herman <[email protected] >> <mailto:[email protected]>> wrote: >> >> I wondered if someone was going to make this point. >> >> > That should be >> > >> > while (!{}.hasOwnProperty.call(obj, key)) >> > >> > which works even if obj has an own property named 'hasOwnProperty'. >> >> Not if someone mutates Object.prototype.hasOwnProperty or >> Function.prototype.call. I don't think we need to polish a proof >> of concept. >> >> >> First, I agree that for the original purpose of this thread, this >> polishing is irrelevant, so I have changed the subject. But your >> counter-examples do help to highlight something I've been thinking >> about. Because of such pervasive mutability, we really haven't had a >> clear notion of "correctness" for JavaScript. For normal JavaScript >> programs, if run after some other code has already mutated that >> environment's primordials arbitrarily, there's so little they can >> count on that very few programs could be written "correctly" under >> these onerous assumptions[1]. For the notion of "correctness" in >> JavaScript to be useful, I think we must allow JavaScript programs to >> rely on the primordial at least continuing to obey their original >> contract. However, the use of objects as maps from strings to values >> is pervasive, e.g., in JSON unserialization, so we should not allow >> general purpose JavaScript programs to rely on, for example, >> 'hasOwnProperty' not being overridden. >> >> Retrofitting a reasonable theory of correctness after the fact is a >> tricky exercise. The above theory represents a practical compromise >> between the assumption that common programs make (primordials obey >> their original contracts) vs. the assumptions that common programs >> break (hasOwnProperty is not overridden). Thus, I claim that the >> original program should not be considered "correct", while the >> modified program should, despite the problematic cases raised by your >> counter-example. >> > > As I see it, you address the "issue" of unstratified meta-programming > (note, I take the "issue" in quotes, since there's no a single meaning > whether the unstratified meta-level is so bad). > > It depends on how to look on the issue. On one hand, why if a user > changes the behavior of the `hasOwnProperty` of _his_ object in _his_ > program, then the program should be considered as incorrect? The user > knows how to handle `hasOwnProperty` for the particular object and the > ability to override it is the ability to control unstratified > meta-level via simple reassigning to meta-hooks. >From what I understand of Mark's definition of correctness, this case is not excluded. My understanding is that Mark tries to provide a uniform meaning to answers to questions like "is this piece of code /correct/?". I interpret what he said as "a program can be considered as correct if it does what we expect it to do within a fresh ES environment". With that interpretation in mind, if the program you want to evaluate redefines Object.prototype.hasOwnProperty and uses consistently this new definition to achieve its goal, then it will be considered correct.
One property of this definition must be noted. Appending two independently "correct" programs may result in an incorrect program (if the first one changes a piece of environment on which the second relies). Most of what you said afterward regarded dynamic validation, I think, which wasn't part of Mark's definition as I understand it (I agree on what you said, though). Cheers, David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
