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

Re: [jslint] Re: ES5

Expand Messages
  • 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 1 of 11 , May 24, 2009
    View Source
    • 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 2 of 11 , May 25, 2009
      View Source
      • 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 3 of 11 , May 26, 2009
        View Source
        • 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 4 of 11 , May 27, 2009
          View Source
          • 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.