On May 27, 2012, at 6:42 PM, John J Barton wrote: > 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.
No that's not how it is specified. Freezing works exactly the same and is mode independent. What varies between modes is the semantics of the assignment operator which is defined in terms of the PutValue abstract operation. PutValue responds differently to frozen objects based upon whether the assignment occurs in strict or non-strict code. > > 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. It is modal, but it is a characteristic of the code not the object. > >> >> 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, you need to realize that there is really no such thing as a "frozen object". Individual properties may be non-configurable and non-writable. The object itself is either extensible or non-extensible (properties may/may-not be added). ES1-3 already defined the behavior of assigning to non-writable property. Such writes were specified by ES1-3 to be silently ignore. To do otherwise in non-strict ES5 would have been a breaking change. Non-extensible objects were a new concept for ES5. You can debate the chosen behavior, but for non-strict code it is generally consistent with how ES has traditionally handled similar impossible to fulfill requests. It is what it is. > >> >> 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. No, read the spec. You seem to be perceiving something different than what is actually occurring. > >> >> >> 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. that would be an alternative design (for the non-extensible case of trying to add a new property) but it's not the design that was chosen for ES5. Whether you like or dislike the that choice, it's water under the bridge. Allen > > jjb > >> >> Allen >> >> >> > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
