Assigning to ReadOnly properties

[Lars T Hansen]

On Nov 12, 2007 4:25 PM, Brendan Eich <brendan at mozilla.org> wrote:
> On Nov 12, 2007, at 4:01 PM, Mark Miller wrote:
>
> > To fix delete within this constraint, "delete <whatever>" in Caja
> > either return true or throws.
>
> At this point, either ES4 slides down the slippery slope a bit and
> courts migration pain that holds it back (we really do expect most
> pages on the web today to work if shipped as application/
> ecmascript;version=4 or application/javascript;version=2); or I think
> we need a better pragma story.
>
> We could support
>
>    use DeleteError, ReadOnlyError
>
> and encourage users to litter their new code with this line at the
> top. There's good precedent from Perl and other languages for a
> superstitious
>
>    use strict
>
> at the top. But the Errors are a mouthful and eyeful. Since I just
> mentioned strict mode, I'll note again that the single runtime
> semantic change strict mode causes from standard mode (assuming the
> program passes strict mode's type checker and lint-like sanity
> checker) is a change to eval: strict mode results in a different
> runtime eval, such that eval cannot create bindings in its dynamic
> scope. We could slide down *this* slope a bit by adding DeleteError
> and ReadOnlyError exception behavior to 'use strict'.
>
> Comments welcome, but you're probably in favor of opt-in versioning
> making all of these changes implicitly ;-). Or perhaps a 'use Caja'
> pragma :-P.

IMO the only sane thing to do in this regard, if we were to do
anything, is to add what we consider bug-fixing behavior to the
effects of "use strict".  We've already hung the eval change there,
and though I don't remember right now if "with" has to be "reformed
with" in strict mode I know we've talked about it (obviously this is a
syntactic constraint only); if everyone agrees that deleting an
unknown property would be an error in a rational world, or that
writing to a read-only property should be, then these are clear
language bugs that don't need their own knobs.  We need knobs, but too
many knobs are if anything worse than none at all.

We made a very special exception for eval wrt changing run-time
semantics in strict mode for the code in the scope of the "use strict"
pragma, and we've been careful to state that it's the exception that
proves the rule: no run-time differences between strict and standard
modes.  The question about the bug fixes for delete and read-only
properties is: are these errors so important and wide-spread that they
warrant breaking that rule?  The value of the rule is that "use
strict" gives you verification only, after that you don't have to
remember anything special (except for the change to eval); if we
attach these bug fixes to the same rule, then (a) where do we stop and
(b) is the language better, worse, or just different?

--lars