Call for opinions: attribute defaults and renaming "flexible"

Ingvar von Schoultz ingvar-v-s at
Sat Sep 6 01:17:03 PDT 2008

Mark S. Miller skrev:
> On Fri, Sep 5, 2008 at 11:44 PM, Ingvar von Schoultz
> <ingvar-v-s at> wrote:
>> Mark S. Miller skrev:
>>> So use strict mode; that's the kind of thing it's for.
>> Sure, but as I said, there will always be those who find that
>> unsuitable, or who find that it breaks the old code that they
>> must work with. It's very undesirable that the non-strict mode
>> become bad quality.
>> And failing silently here is very bad quality.
> Strict mode is there to provide those quality-supporting rules that
> are not sufficiently compatible to propose for the non-strict
> language. You propose to throw an error for a case that is currently
> silent *both* according to the ES3 spec and by all browser behaviors.
> Any behavior where the ES3 spec and all browsers currently agree is
> likely to be legacy we can't break.
> We have considered making some breaking changes conditional on version
> opt-in rather than strictness-opt-in. But in all cases, it is to
> support additional functionality (lexically nested named functions,
> new keywords, both of which are technically compatible within the
> language of ES3). If you want to propose turning off old functionality
> for the sake of quality, or to turn silent failures into noisy ones,
> again, that's what strict mode is for.

I did propose a fully compatible variant where silent failure
occurs in all the situations where it occurs today, and noisy
failure occurs only in new situations that can't arise today:

|  In that case, suppose instead silent failure is limited to
|  those few objects only. The rule could be simple: All native
|  constructors, all RegExp instances, and .length on functions.

Those are the only ReadOnly cases that exist in ES3.

This would essentially make it noisy where it matters, on objects
configured with Object.configure(), and silent where it doesn't
matter much, on objects where configuring isn't very useful anyway.

If making these rare write bugs noisy is too great a change, then
switching an old program to strict mode is a far more dramatic
change that will introduce far more breakage, and therefore in
many cases it just isn't a viable option.

It's very good that strict mode exists, but it mustn't become
an excuse for giving non-strict less care. If the quality of
non-strict can be significantly improved, it's worth careful

Ingvar von Schoultz

More information about the Es-discuss mailing list