Sure, I'll buy that. There's a qualitative difference in how uncooperatively
your program is behaving if it mutates primordials to violate their usual
contracts, as opposed to simply creating an object that overrides
hasOwnProperty, which ought to be allowed.
The word "theory" might be a little loaded, but at least "practical advice on
how to write reasonable/cooperative code" is important for programmers to know
how to avoid unintended (i.e., not malicious) interactions between different
interacting bits of JS code. I think this is part of what good JS programmers
have to learn, and to date there's sadly not enough good, authoritative
material with that kind of advice ("how not to be anti-modular").
Dave
On Apr 11, 2011, at 7:07 AM, Mark S. Miller wrote:
> On Sun, Apr 10, 2011 at 11:21 PM, David Herman <[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.
>
>
> [1] SES initialization freezes the primordials, so SES programs can safely
> assume they are frozen. But the point I'm making here are not specific to SES.
>
>
> Dave
>
>
>
>
> --
> Cheers,
> --MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
