On Sun, May 27, 2012 at 6:04 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On May 27, 2012, at 5:13 PM, John J Barton wrote: > > ... > The reason I asked is that "use strict" seems to be a subset but acts > like another version in some cases. In particular, if a library uses > obj.freeze() and the caller modifies the object by adding a property, > the caller gets no error message. (You'll have to read the source of > the library to figure it out.) The library is, for this purpose, > operating in a language where object modification is an error but the > caller is not. > > > A don't follow your logic. "Freezing" is independent of strict mode. It > is a characteristic of the object model, not the source code "mode". What is > determined by strict mode is what happens when code for that mode tries to > modify a frozen object. It can either cause an exception (strict mode) or > for be silently ignored (non-strict mode).
Freezing is not independent of strict mode because a frozen object can be passed between strict and non-strict mode source code. The object behaves differently in these two environments. When a frozen object is passed to normal JavaScript code, normal JavaScript operations silently fail. IMO this is the worst kind of modal language result. > > If the library writer thinks that freezing will always cause exceptions, > then they don't understand either strict mode or what Object.freeze actually > does. I would generally have higher expectations for library writers. I have higher expectations for the language: modifying frozen objects should *always* throw exceptions. > > First rule of strict mode: "use strict" only affects code that is lexically > within the scope of the directive. It has no global effect. My example contradicts this claim. > > > If 'mashing up' is similar to 'using objects from a library', then > isn't JS-mashed-with-SES (whatever that means) a different version of > JS? > > > Yes...no...when passing object into any library you need to be aware of the > library's expectations for those objects. It should be part of the > documented interface contract for the library. strict/non-strict, SES or > plain old JS, garbage in usually results in garbage out In this case the library provides the objects. Of course your truism applies, but to me, objects with silent new behavior should not be a matter of documentation. jjb > > Allen > > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
