On Tue, May 29, 2012 at 12:07 AM, John J Barton <[email protected] > wrote:
> On Mon, May 28, 2012 at 10:50 AM, T.J. Crowder <[email protected]> > wrote: > > On 28 May 2012 18:46, Russell Leggett <[email protected]> wrote: > >>> > >>> Perhaps this discussion would be aided by a more concrete example. > > > > Doh! Excellent idea. John, if you'd like...? (Otherwise I can do one.) > > Here's mine: > Source: > https://github.com/johnjbarton/webdev-examples/tree/gh-pages/Freeze > Site: > http://johnjbarton.github.com/webdev-examples/Freeze/app.html > > The application function app() calls the library function > makeExample(), adds a method to it, then calls that method: > function app() { > var r = makeExample(); > r.discover = function() { > console.log("I want to call this function"); > return 1; > }; > r.discover(); > } > > The result is an error message at the > Uncaught TypeError: Object #<Object> has no method 'discover'. > This would be the case no matter whether the library were written in strict mode or not. Because you aren't using strict, you don't get the initial error when you try to write to the frozen object. > > Note that lib.js is to be written by someone else and overall they do > a great job. They choose 'use strict' and freeze(); that decision is > sound. > > I am calling that library. I extend their object in order to fit it > into other libraries I use. > > Now imagine that r.discover() is call somewhere else and -- I know > this is hard -- imagine you know nothing about the discussion above. > > Maybe my debug skills are not great, but I eventually had to resort to > executing the library code single stepping to figure out why the > method call failed. > This just goes to show that it was useful to add the error to strict mode. Are you suggesting that the error should throw even in non-strict mode? > > I want to just re-iterate that the issue here is not my negative > opinions on the two ingredients, 'use strict' (IMO pointless extra > typing) and 'freeze() (IMO not JS). The issue here is the modal > object model created from the combination and how to avoid repeating > that mistake. Without the modal object model, the library writer can > 'use strict' and 'freeze()', and I can live with the result or not use > the library. With the modal object model I don't get a choice: I have > to debug the library line by line to discover I can't use it. > It seems to me that your problem is really that you dislike non-strict mode's behavior when trying to modify a frozen object. This has nothing to do with what you call a modal object model. There is nothing different about the object because it came from a strict environment vs a non-strict environment. It has to do with you using it in a strict vs non-strict environment. Really its like deciding whether or not to use the gcc -Werror flag, which you can use to turn warnings into errors. Granted, in this case you don't even get a warning, but you get the idea. - Russ > > jjb > > > > > -- T.J. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
