On Mon, May 28, 2012 at 9:41 PM, Russell Leggett <[email protected]> wrote: > > > 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?
No. I am suggesting that Object.freeze() should not have been added to the language unless an error was thrown when the object is modified, full stop. Having a feature like Object.freeze() that does not give an error when you modify the object is unreasonable. I'm completely baffled that reasonable engineers would disagree with this position. The coupling between freeze() and "use strict" comes exactly because library engineers would not use freeze() if they knew that it gave no errors. But because the library engineers "use strict" they don't know that their users may suffer from this language defect. Or to say it another way, if the error were thrown in non-strict mode, then I would not complain to you I would complain to the library writer. Again "should not have been" means "let's not make this mistake again". > >> >> >> 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. You are looking at the wrong part of this problem. You are looking at the object. This problem is not about the object. The problem is the library is built and tested under 'use strict' where freeze() makes sense to apply because it will prevent some kinds of problems and not cause more. But the use of the library is not under 'use strict' and freeze() is not reasonable. The object is the same, but the library writer and I have very different assumptions about the object. We are both doing reasonable programming with different object models. That is the problem. jjb > 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
