On 28 May 2012 17:34, John J Barton <[email protected]> wrote:
> > On May 28, 2012 2:53 AM, "T.J. Crowder" <[email protected]> wrote: > > > > On 28 May 2012 06:37, John J Barton <[email protected]> wrote: > >> > >> A library writer creates an object in one scope and all of their tests > >> succeed. I use it another scope and my code fails. We are both using > >> legal statements. How can this not be a global effect? > > > > > > You're both using legal statements in the mode (variant) of the language > that _you_ have chosen to use in your execution context. > > Unfortunately I am not successful in communicating the problem here. > > In the example I described both variants are in the same execution context. > They cannot be. Strict mode applies throughout the execution context in which it's declared. The library code is within its execution context. Your code is within your context. They are separate. They can _communicate_, but they are separate. JavaScript has always had read-only properties (ex: Object.prototype, > Function#length, Number.MAX_VALUE), and prior to ES5 always had writes to > read-only properties fail silently. Object.freeze, Object.defineProperty, > and the like give us new ways to _create_ read-only properties, but > read-only properties are neither new nor do they create a new "global > effect." > > How can changes to the object model in a language the supports passing > objects not be global? > It's not a change to the object model. Again, JavaScript has had read-only properties for a long time (see my examples above), certainly since 1998 and I would assume prior to that as well. > For my money, the far bigger mistake would be to have different kinds of > read-only properties: Ones that fail silently for legacy reasons, and one > that throw even in non-strict mode. Far better to have a consistent view of > read-only properties within a given execution context, where the author > decides whether they want silent failures or exceptions. > > Sorry I don't follow your logic here. I am arguing for more consistency. > 1JS, not "author's choice". > I think you're using 1JS differently than Brendan is, but if so presumably he'll address that. Regardless of terminology: We can't retroactively change the behavior of read-only properties in non-strict mode, just like we can't retroactively fix the Horror of Implicit Globals, without breaking code that currently works. So that means either A) Making two kinds of read-only property, legacy and modern, where writes to legacy ones continue to fail silently and writes to modern ones throw. Yuck. Or B) Making modern read-only properties behave consistently with the legacy ones, and providing a means to say "I don't care whether they're old or new, I want writes to legacy properties to throw" (and lots of other good stuff; e.g., the strict variant). TC39 very intelligently opted for the second option with ES5. This keeps the old code working, while improving the language. -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
