Loading ...
Sorry, an error occurred while loading the content.

ES5

Expand Messages
  • Douglas Crockford
    There was a good talk at Google about the language changes.
    Message 1 of 11 , May 20, 2009
    • 0 Attachment
      There was a good talk at Google about the language changes.

      <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
    • pauanyu
      ... Very nice. Thanks for posting; it answered some of my questions.
      Message 2 of 11 , May 20, 2009
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
        >
        > There was a good talk at Google about the language changes.
        >
        > <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
        >

        Very nice. Thanks for posting; it answered some of my questions.
      • iamonlyhereforpipes
        ... I ve bad feeling about this. The talk is nice in a sense of giving an idea about changes to come. But there is a feature, that once introduced, will be for
        Message 3 of 11 , May 20, 2009
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
          >
          > There was a good talk at Google about the language changes.
          >
          > <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
          >

          I've bad feeling about this. The talk is nice in a sense of giving an idea about changes to come. But there is a feature, that once introduced, will be for sure a big gamechanger for many people.

          I'm talking about Object.freeze function (and its companions Object.seal and Object.preventExtensions).

          The future looks bleak, because once introduced into language (and once the language spreads to all major browsers) the unavoidable ice age will start. Maybe I'm overreacting here, but I've had stared at 'sealed' or 'private' keyword cursing helplessly many times.

          The idea of protection of object state is good in theory but lacks in application. Authors will never anticipate all possible uses of their creations. Javascript is now a 'fair use' language - if one wants to tinker with others stuff, one is free to do so. Not anymore once Ecmascript5 hits the market.

          Object.{freeze,seal,preventExtensions} are one way road. I just know that everyone will abuse the hell out of them. And those who would like to reuse code will have to resort to hacks - once freezed, object cannot be unfreezed. Combine this with default values of [[Writable]], [[Enumerable]], [[Configurable]] attributes for properties which are false!

          The whole thing is just an injection of "DRM for the code" in a place, that as for now is free from it.

          Citation found on internet: "I see a name of another plugin for Firefox - Object.unfreeze"

          I'd call it 'Object.melt' :)

          What are your thoughts about this?
        • christian.wirkus
          Overloading a language is bad. You re right. But this feature looks really really good. And languages that don t change are dead. And what do you want to do?
          Message 4 of 11 , May 21, 2009
          • 0 Attachment
            Overloading a language is bad. You're right. But this feature looks really really good. And languages that don't change are dead.

            And what do you want to do? Include a library and change its properties?
            I don't think that's a good idea. If the library changes, your augmenting will probably fail or cause trouble; the defined interfaces of that library on the other hand probably won't change.

            Or we write a library or game of our own. The user who includes it, might include three other libraries as well. And he might not have checked, what the code of these look like.
            Better he gets an exception, as soon as there are interferences; and not letting things augment or change silently until one augmentation some time after including everything causes a weird bug.

            Also: I could create an object of constants; I could just look at the objects definition to know what is in there. And what I need to change.
            I don't need to trace down where the properties where changed because one of my coworkers (or myself in sudden insanity) thought it a neat container for some stuff he just needs to store somewhere for a little while.

            var all_my_constants = {
            "ajax_news_url" : "...",
            ...
            };

            Christian



            --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes" <iamonlyhereforpipes@...> wrote:
            >
            > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
            > >
            > > There was a good talk at Google about the language changes.
            > >
            > > <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
            > >
            >
            > I've bad feeling about this. The talk is nice in a sense of giving an idea about changes to come. But there is a feature, that once introduced, will be for sure a big gamechanger for many people.
            >
            > I'm talking about Object.freeze function (and its companions Object.seal and Object.preventExtensions).
            >
            > The future looks bleak, because once introduced into language (and once the language spreads to all major browsers) the unavoidable ice age will start. Maybe I'm overreacting here, but I've had stared at 'sealed' or 'private' keyword cursing helplessly many times.
            >
            > The idea of protection of object state is good in theory but lacks in application. Authors will never anticipate all possible uses of their creations. Javascript is now a 'fair use' language - if one wants to tinker with others stuff, one is free to do so. Not anymore once Ecmascript5 hits the market.
            >
            > Object.{freeze,seal,preventExtensions} are one way road. I just know that everyone will abuse the hell out of them. And those who would like to reuse code will have to resort to hacks - once freezed, object cannot be unfreezed. Combine this with default values of [[Writable]], [[Enumerable]], [[Configurable]] attributes for properties which are false!
            >
            > The whole thing is just an injection of "DRM for the code" in a place, that as for now is free from it.
            >
            > Citation found on internet: "I see a name of another plugin for Firefox - Object.unfreeze"
            >
            > I'd call it 'Object.melt' :)
            >
            > What are your thoughts about this?
            >
          • iamonlyhereforpipes
            I m replying below ... Well, I didn t try to say that this language changes are bad. In fact I also think that freeze/seal/preventExtensions are good in
            Message 5 of 11 , May 23, 2009
            • 0 Attachment
              I'm replying below

              --- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...> wrote:
              > --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes" <iamonlyhereforpipes@> wrote:
              > > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
              > > >
              > > > There was a good talk at Google about the language changes.
              > > >
              > > > <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
              > > >
              > >
              > > I've bad feeling about this. The talk is nice in a sense of giving an idea about changes to come. But there is a feature, that once introduced, will be for sure a big gamechanger for many people.
              > >
              > > I'm talking about Object.freeze function (and its companions Object.seal and Object.preventExtensions).
              > >
              > > The future looks bleak, because once introduced into language (and once the language spreads to all major browsers) the unavoidable ice age will start. Maybe I'm overreacting here, but I've had stared at 'sealed' or 'private' keyword cursing helplessly many times.
              > >
              > > The idea of protection of object state is good in theory but lacks in application. Authors will never anticipate all possible uses of their creations. Javascript is now a 'fair use' language - if one wants to tinker with others stuff, one is free to do so. Not anymore once Ecmascript5 hits the market.
              > >
              > > Object.{freeze,seal,preventExtensions} are one way road. I just know that everyone will abuse the hell out of them. And those who would like to reuse code will have to resort to hacks - once freezed, object cannot be unfreezed. Combine this with default values of [[Writable]], [[Enumerable]], [[Configurable]] attributes for properties which are false!
              > >
              > > The whole thing is just an injection of "DRM for the code" in a place, that as for now is free from it.
              > >
              > > Citation found on internet: "I see a name of another plugin for Firefox - Object.unfreeze"
              > >
              > > I'd call it 'Object.melt' :)
              > >
              > > What are your thoughts about this?
              > >
              >
              > Overloading a language is bad. You're right. But this feature looks really really good. And languages that don't change are dead.

              Well, I didn't try to say that this language changes are bad. In fact I also think that freeze/seal/preventExtensions are good in certain way. What I try to argue is that theese functions are one way road!

              Why it is 'access-control' dangerous?

              Consider applying external scripts to existing web pages, ala Greasemonkey. You know why it works? Because there is no access-level in DOM. DOM is not 'freezed' in any way. A script executed in context of any page can do anything to its contents. This is the case for Greasemonkey, for bookmarklets.

              How does it apply to JS?

              Scripts are part of page. If some parts of them are 'freezed' it means they're untouchable for you! No changes allowed! With DOM do what you want, with scripts not so anymore (if developers will used, and I'm sure they'll do, just search the web for cries 'where's private in JS?').

              We're witnessing a step in direction of implanting 'access-control' language constructs to JS. And I'm sure all devs who ever heard of defensive programming will freeze everything _they_ think is unneccessary for users(devs) of their frameworks.

              Creator limits uses of his/her creation? Well, doesn't that ring a bell? The fight is ongoing on many levels in out culture right now. This is the 'fair-use' thing. Users want to relax controls over stuff they posses! Tinker with it, transfer it wherever thay like!


              >
              > And what do you want to do? Include a library and change its properties?

              Exactly, I'd like to have this capability at hand. I'm assuming you are developer, didn't you ever got stuck on some lib because its author didn't forsee the use that you'd like to apply? I'm finding myself frequently at this position. And that's when the hacking starts.

              > I don't think that's a good idea. If the library changes, your augmenting will probably fail or cause trouble; the defined interfaces of that library on the other hand probably won't change.

              If I tinker with something and it breaks it is my problem. If I sell something that because of changing world breaks my clients could sue me. Guess why all software has this fun clauses about limited accountability :)

              The academia mantra about ideal world with 'defined interfaces'... I fully understand that utopian notion. But it's not here, never was.

              >
              > Or we write a library or game of our own. The user who includes it, might include three other libraries as well. And he might not have checked, what the code of these look like.
              > Better he gets an exception, as soon as there are interferences; and not letting things augment or change silently until one augmentation some time after including everything causes a weird bug.

              This is a good point. With freezing etc there will be an exception thrown (if the code that does invalid change is called).

              Let's say there is an 'unfreeze' class of methods (reciprocal to proposed 'freeze/seal/...'). Those will be intended for anarchs like me to open up stuff and tinker :) But, some framework devs will also use them so the problem that you brought up is serious.

              You know what? I think that this is a problem without perfect solution. But I also think that the solution proposed in ES5 draft is not good enough. They give dev a mean to lock the door. And there is no way for other dev to open it.

              >
              > Also: I could create an object of constants; I could just look at the objects definition to know what is in there. And what I need to change.
              > I don't need to trace down where the properties where changed because one of my coworkers (or myself in sudden insanity) thought it a neat container for some stuff he just needs to store somewhere for a little while.
              >
              > var all_my_constants = {
              > "ajax_news_url" : "...",
              > ...
              > };
              >
              > Christian

              This thing I also understand very well. In Java, C#, C++ you have means to repell that, to shut things down. When you go to JS, you feel so insecure (I'm not joking on you, this is how I feel). Everybody can just write anything they like in my stuff! I've to check everything twice, or even thrice, or just go nuts :)

              I think that good-enough solution is just relax and live with that openess.

              And I see that this open JS is going to die soon. Doesn't feel good to me.
            • Douglas Crockford
              ... If you don t have enough confidence in your skills to use the strict mode, don t worry. You don t have to. The sloppy mode is still there by default, and
              Message 6 of 11 , May 23, 2009
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes"
                > And I see that this open JS is going to die soon.
                > Doesn't feel good to me.

                If you don't have enough confidence in your skills to use the strict mode, don't worry. You don't have to. The sloppy mode is still there by default, and will continue to accept all of the bad practices that the web is famous for.

                JavaScript has always been on the forefront of highly distributed casual programming, and surprisingly, offers a better security model than most other languages. Unfortunately, it is not sufficient to support mashups, and it has never been sufficient to repel XSS attacks.

                ES5 Strict begins to move the language in that direction. ES5 Strict is very compatible with The Good Parts. If your code is passing JSLint (and it should) then ES5 should strictly improve things for you.
              • iamonlyhereforpipes
                ... That is not the answer for issue that I try to raise. Object.{freeze,seal,preventExtensions} usage has nothing to do with strict mode (am I correct here?).
                Message 7 of 11 , May 24, 2009
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                  >
                  > --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes"
                  > > And I see that this open JS is going to die soon.
                  > > Doesn't feel good to me.
                  >
                  > If you don't have enough confidence in your skills to use the strict mode, don't worry. You don't have to. The sloppy mode is still there by default, and will continue to accept all of the bad practices that the web is famous for.

                  That is not the answer for issue that I try to raise.

                  Object.{freeze,seal,preventExtensions} usage has nothing to do with strict mode (am I correct here?).

                  As for the 'bad practices' you mentioned - I've seen those, but in frantic abuse of access-control keywords (protected/private/internal/sealed/...) in frameworks/libraries. And by introducing to JS one-way 'freezers' we're soon have to welcome this problem.

                  In short: you will not hava a chance to fix issues in someones code, because it will be tightly freezed.

                  And from my experience, there is lot's of sloppy lib code in languages supporting access-control notion. 'strict mode' will not fix developers stupidity and misunderstanding of proper coding practices.

                  > JavaScript has always been on the forefront of highly distributed casual programming, and surprisingly, offers a better security model than most other languages. Unfortunately, it is not sufficient to support mashups, and it has never been sufficient to repel XSS attacks.

                  I wonder how many devs hit the wall while trying to do some mashuping - because of restrictions invented to stop XSS.

                  I'm sure that many devs will soon hit the wall because of this new 'freeze' stuff.

                  > ES5 Strict begins to move the language in that direction. ES5 Strict is very compatible with The Good Parts. If your code is passing JSLint (and it should) then ES5 should strictly improve things for you.

                  The 'strictness' is not the point. I would like not to get into 'strict mode', it's irrelevant for 'freeze'.

                  So, to sum it up:

                  There long awaited code/data access control is coming to JS. Every code monkey trained to (ab)use sealed (as in .NET) keyword will be very happy. The very well though interfaces will be exposed, and no extending will be allowed. And the user of this now-so-good code will have no method to unfreeze/unseal/allowExtensions, will have no control over the code that is at his hands.

                  It is another story when you create good libs that everyone uses.

                  And a whole different story when you use what you got and it is written by an idiot.
                • Mike West
                  On Sun, May 24, 2009 at 11:34 AM, iamonlyhereforpipes ... One of the very nice things about JavaScript is that the source for the libs you re forced to use
                  Message 8 of 11 , May 24, 2009
                  • 0 Attachment
                    On Sun, May 24, 2009 at 11:34 AM, iamonlyhereforpipes
                    <iamonlyhereforpipes@...> wrote:

                    > And a whole different story when you use what you got and it is written by an idiot.

                    One of the very nice things about JavaScript is that the source for
                    the libs you're "forced" to use is generally available. If you run
                    into an issue with a library that absolutely, positively requires you
                    to override some functionality that you don't have the ability to
                    programatically access, you have the ability to fork the library,
                    change the code to your liking, and use your improved version.


                    -Mike
                  • christian.wirkus
                    I think you re worried too much of that new feature; privacy is possible in Javascript right now and completely ignored by an overwhelming majority of
                    Message 9 of 11 , May 25, 2009
                    • 0 Attachment
                      I think you're worried too much of that new feature; privacy is possible in Javascript right now and completely ignored by an overwhelming majority of Javascript developers.

                      var o = (function () {
                      var private = "dontyoulookatme";
                      return {
                      out : function () {
                      alert(private);
                      }
                      };
                      }())

                      //won't change private
                      o.private = "lookatmeanyway";
                      o.out();

                      But actually: JSLint is a code quality tool. If you write code that overrides properties of a library, something that you just can prove to work in one very special release of that library, you are leaving code quality. However skillful it might be.

                      I wonder if that would work:

                      // if thats your lib
                      var frozen_lib = {
                      frozen_stuff : function () {}
                      }.freeze();

                      // do that
                      var melted_lib = Object.create(old);
                      melted_lib.frozen_stuff = "something different";


                      Christian

                      ps. i wish indenting would survive in here


                      --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes" <iamonlyhereforpipes@...> wrote:
                      >
                      > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
                      > >
                      > > --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes"
                      > > > And I see that this open JS is going to die soon.
                      > > > Doesn't feel good to me.
                      > >
                      > > If you don't have enough confidence in your skills to use the strict mode, don't worry. You don't have to. The sloppy mode is still there by default, and will continue to accept all of the bad practices that the web is famous for.
                      >
                      > That is not the answer for issue that I try to raise.
                      >
                      > Object.{freeze,seal,preventExtensions} usage has nothing to do with strict mode (am I correct here?).
                      >
                      > As for the 'bad practices' you mentioned - I've seen those, but in frantic abuse of access-control keywords (protected/private/internal/sealed/...) in frameworks/libraries. And by introducing to JS one-way 'freezers' we're soon have to welcome this problem.
                      >
                      > In short: you will not hava a chance to fix issues in someones code, because it will be tightly freezed.
                      >
                      > And from my experience, there is lot's of sloppy lib code in languages supporting access-control notion. 'strict mode' will not fix developers stupidity and misunderstanding of proper coding practices.
                      >
                      > > JavaScript has always been on the forefront of highly distributed casual programming, and surprisingly, offers a better security model than most other languages. Unfortunately, it is not sufficient to support mashups, and it has never been sufficient to repel XSS attacks.
                      >
                      > I wonder how many devs hit the wall while trying to do some mashuping - because of restrictions invented to stop XSS.
                      >
                      > I'm sure that many devs will soon hit the wall because of this new 'freeze' stuff.
                      >
                      > > ES5 Strict begins to move the language in that direction. ES5 Strict is very compatible with The Good Parts. If your code is passing JSLint (and it should) then ES5 should strictly improve things for you.
                      >
                      > The 'strictness' is not the point. I would like not to get into 'strict mode', it's irrelevant for 'freeze'.
                      >
                      > So, to sum it up:
                      >
                      > There long awaited code/data access control is coming to JS. Every code monkey trained to (ab)use sealed (as in .NET) keyword will be very happy. The very well though interfaces will be exposed, and no extending will be allowed. And the user of this now-so-good code will have no method to unfreeze/unseal/allowExtensions, will have no control over the code that is at his hands.
                      >
                      > It is another story when you create good libs that everyone uses.
                      >
                      > And a whole different story when you use what you got and it is written by an idiot.
                      >
                    • iamonlyhereforpipes
                      Sure, privacy in JS is possible (anon functions with local vars). But the freeze/seal/preventExtensions is not about private stuff in a way that your
                      Message 10 of 11 , May 26, 2009
                      • 0 Attachment
                        Sure, 'privacy' in JS is possible (anon functions with local vars).

                        But the freeze/seal/preventExtensions is not about private 'stuff' in a way that your example shows.

                        You'll be soon given objects that you cannot modify.

                        Think about debugging a program (say written in C) in your favorite debugger. At every moment you can change value in processor registers or in memory.

                        Isn't it clear to you that similiar manipulations no longer apply to freezed objects in ES5 (those with [[Writable]] false)? How do you think it will affect debugging? What about firebug?

                        As I found in a blog comment (http://ejohn.org/blog/ecmascript-5-objects-and-properties/#comment-384509, written by Dougal Campbell:
                        """ So, would you be able to do something like "Object.seal( document )" for a quick-n-dirty greasemonkey browser security hack? I hope the browsers don't let you freeze() the window object :) """

                        Let's discuss this. What does it mean for casual web browsing user? Next to nothing. What working Object.seal(document) means for web page developer? Well, it depends... Keep in mind a right-click JS context menu hijack still present in some pages. Cool huh? "I'm not sure, so let seal everything". Still ok?

                        Ever heard of bookmarklets? Snippets of JS that you can 'inject' into pages? Greasemonkey lite :) You can write very cool utils, like 'open in tabs' for iPhone... Yeah, let's seal everything so it's no longer possible, but instead, out mature and rigid language will allow writing serious code thats guarded agains rogue changes of those pesky hackers :)

                        There is a nice feature that is rarely used in web dev, called expando. I was pretty amazed that it works consistently across browsers. It works like that: you can invent your own attributes of html elements and give them values. Later, you can access them using JS. I use it from time to time, it is cheaper than JS arrays generated on the side. Keeps data local.

                        So, what happens if I use a lib and it generates freezed DOM objects? I cannot unfreeze them and set my attributes on them... Worse, the lib can freeze existing objects, so that my expandos stop working.

                        ES5 doesn't state what is the effect of calling freeze and family on DOM. We'll see.

                        I think that what will see in the future will prove my point, the cure will be worse than the disease.

                        I'm sorry to pour my rants in jslint group, I've to wrap it up and publish for the record in consise way. Yet, I do not belive that ES5 authors would change something now. From the ideallistic point of view they're right. I've woken up too late.


                        --- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...> wrote:
                        >
                        > I think you're worried too much of that new feature; privacy is possible in Javascript right now and completely ignored by an overwhelming majority of Javascript developers.
                        >
                        > var o = (function () {
                        > var private = "dontyoulookatme";
                        > return {
                        > out : function () {
                        > alert(private);
                        > }
                        > };
                        > }())
                        >
                        > //won't change private
                        > o.private = "lookatmeanyway";
                        > o.out();
                        >
                        > But actually: JSLint is a code quality tool. If you write code that overrides properties of a library, something that you just can prove to work in one very special release of that library, you are leaving code quality. However skillful it might be.

                        I understand your point. Try to fully understand mine, do not look at this issue from the academic perspective but rather considering everyday usage.

                        >
                        > I wonder if that would work:
                        >
                        > // if thats your lib
                        > var frozen_lib = {
                        > frozen_stuff : function () {}
                        > }.freeze();
                        >
                        > // do that
                        > var melted_lib = Object.create(old);
                        > melted_lib.frozen_stuff = "something different";

                        I'm not sure what you intended to do here. I would like to see:

                        function hacky() {
                        var melted_lib = Object.unfreeze(frozen_lib);
                        melted_lib.frozen_stuff = "something different";
                        return melted_lib;
                        }

                        and maybe

                        function notsohacky() {
                        "use strict";
                        var melted_lib = Object.unfreeze(frozen_lib);//nop
                        melted_lib.frozen_stuff = "something different";//throws something
                        return melted_lib;
                        }

                        thus, unfreeze would be useful only in non-strict mode, sorta like unsafe in c#.

                        >
                        >
                        > Christian
                        >
                        > ps. i wish indenting would survive in here
                        >
                        >
                        > --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes" <iamonlyhereforpipes@> wrote:
                        > >
                        > > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
                        > > >
                        > > > --- In jslint_com@yahoogroups.com, "iamonlyhereforpipes"
                        > > > > And I see that this open JS is going to die soon.
                        > > > > Doesn't feel good to me.
                        > > >
                        > > > If you don't have enough confidence in your skills to use the strict mode, don't worry. You don't have to. The sloppy mode is still there by default, and will continue to accept all of the bad practices that the web is famous for.
                        > >
                        > > That is not the answer for issue that I try to raise.
                        > >
                        > > Object.{freeze,seal,preventExtensions} usage has nothing to do with strict mode (am I correct here?).
                        > >
                        > > As for the 'bad practices' you mentioned - I've seen those, but in frantic abuse of access-control keywords (protected/private/internal/sealed/...) in frameworks/libraries. And by introducing to JS one-way 'freezers' we're soon have to welcome this problem.
                        > >
                        > > In short: you will not hava a chance to fix issues in someones code, because it will be tightly freezed.
                        > >
                        > > And from my experience, there is lot's of sloppy lib code in languages supporting access-control notion. 'strict mode' will not fix developers stupidity and misunderstanding of proper coding practices.
                        > >
                        > > > JavaScript has always been on the forefront of highly distributed casual programming, and surprisingly, offers a better security model than most other languages. Unfortunately, it is not sufficient to support mashups, and it has never been sufficient to repel XSS attacks.
                        > >
                        > > I wonder how many devs hit the wall while trying to do some mashuping - because of restrictions invented to stop XSS.
                        > >
                        > > I'm sure that many devs will soon hit the wall because of this new 'freeze' stuff.
                        > >
                        > > > ES5 Strict begins to move the language in that direction. ES5 Strict is very compatible with The Good Parts. If your code is passing JSLint (and it should) then ES5 should strictly improve things for you.
                        > >
                        > > The 'strictness' is not the point. I would like not to get into 'strict mode', it's irrelevant for 'freeze'.
                        > >
                        > > So, to sum it up:
                        > >
                        > > There long awaited code/data access control is coming to JS. Every code monkey trained to (ab)use sealed (as in .NET) keyword will be very happy. The very well though interfaces will be exposed, and no extending will be allowed. And the user of this now-so-good code will have no method to unfreeze/unseal/allowExtensions, will have no control over the code that is at his hands.
                        > >
                        > > It is another story when you create good libs that everyone uses.
                        > >
                        > > And a whole different story when you use what you got and it is written by an idiot.
                        > >
                        >
                      • christian.wirkus
                        My fault, I used a wrong variable name, here again: // some frozen lib somewhere var frozen_lib = { frozen_stuff : function () {} // ... }.freeze(); // which I
                        Message 11 of 11 , May 27, 2009
                        • 0 Attachment
                          My fault, I used a wrong variable name, here again:

                          // some frozen lib somewhere
                          var frozen_lib = {
                          frozen_stuff : function () {}
                          // ...
                          }.freeze();

                          // which I wanna use later unfrozen
                          // melted_lib inherits stuff from frozen_lib, here I messed up previously
                          var melted_lib = Object.create(frozen_lib);
                          melted_lib.frozen_stuff = "something different";

                          Object.create is a method for inheritance: http://javascript.crockford.com/prototypal.html

                          What about DOM nodes? I don't think browser makers would give us frozen nodes in their API. That would crash every piece of Javascript ever written for a browser.
                          node.style.color = "red";
                          node.innerHMTL = "Wow";

                          And for every global variable is a property of the global object (in browsers: window), this wouldn't work anymore in a global scope, if window was sealed:
                          var x = 0;

                          It's not going to happen.
                        Your message has been successfully submitted and would be delivered to recipients shortly.