On Mon, May 28, 2012 at 11:23 PM, Brendan Eich <bren...@mozilla.org> wrote:
> John J Barton wrote:
>>
>> On Mon, May 28, 2012 at 10:09 PM, Allen Wirfs-Brock
>> <al...@wirfs-brock.com> wrote:
>>>
>>> On May 28, 2012, at 10:03 PM, John J Barton wrote:
>>>
>>>> So let's rewind to my original question. If the discussion about SES
>>>> is leading us toward more things like freeze(), let's do a better job
>>>> this time.
>>>>
>>> John, could you xplain what you would have done differently with
>>> "freeze()". It's water under the bridge, but perhaps if you can explain
>>> what you would have done we will be better able to understand your concerns.
>>
>>
>> I would ask that the bar for the "freeze()" feature include exceptions
>> on modifications. If this is not feasible, the feature cannot be
>> accepted.
>
>
> The reason JS in 1995 had quirks such as silent failure on attempt to assign
> to a non-writable property was lack of try-catch. ES3 added try-catch, so
> you have a point: ES5 could have made attempting to extend a non-extensible
> object always throw, irrespective of whether the attempt was from strict
> mode code.
>
> However, in that case attempts to assign to non-writable existing properties
> on a non-extensible object (frozen object) would still not throw when made
> from non-strict code, unless ES5 changed the logic for assignment to an
> existing property to check both [[Extensible]] and [[Writable]]. If I can
> even try to recall those days, this seemed inconsistent and illogical. Why
> should assignment
>
> obj.foo = 42;
>
> fail with a thrown exception for obj = Object.freeze({}) and obj =
> Object.freeze({foo:0}) but not for obj = {}; Object.defineProperty(obj,
> 'foo', {value:0})? All three ways of creating obj should either throw on the
> obj.foo = 42 attempt, or not throw.
>
> So the heavy hand of pre-ES3 (pre-try-catch) primeval JS still hangs over
> the language.
Thanks for the explanation.
>
> I don't think this is as bad as you seem to think it is.
This is one of those cases where a small delta creates a very large
negative effect.
>Why not always "use
> strict"; at the top of your code, live long, and prosper?
1) The advertised advantages of "use strict"
(https://developer.mozilla.org/en/JavaScript/Strict_mode) seem very
minor to me. I've never had any of the problems it solves and -- until
recently -- I've never encountered freeze in real code.
2) I had legacy code using "with".
3) Inertia.
In my experience jslint is a much more powerful as a development aid
than 'use strict'. Surprisingly there are still developers who don't
use such tools. I guess they have a similar list to mine above.
I hope the coming generation of development tools will expand to
include dynamic error analysis that won't need to live within the ES
limitations of compatibility.
jjb
>
> /be
>
>
>>
>> If, as seems to be the case, the exceptions are only possible once ES
>> mandates "use strict", then freeze() must wait for that fine day.
>>
>> I believe that is a sensible model.
>>
>> jjb
>>
>>> Allen
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
