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

Re: [jslint] Re: Can we please lose the trailing whitespace and "this" restriction?

Expand Messages
  • John Hawkinson
    ... Only that it is cumbersome, expensive, and inefficient to do so. Forks are not free. They add huge maintenance hassles. They also are rude to the
    Message 1 of 22 , Oct 28, 2011
    • 0 Attachment
      Austin wrote:
      > There are hundreds of forks of JSLint. Nobody is stopping you from
      > creating one of your own.

      Only that it is cumbersome, expensive, and inefficient to do so.
      Forks are not free. They add huge maintenance hassles. They also are
      rude to the community of users, who now needs to figure out what fork
      to use, and to qualify it somehow.

      The idea of "make your own fork" is quite antithetical to the idea of
      sharing that free software is based on. It should be strongly avoided if
      possible.


      So, "nobody is stopping you" is not a good argument. We stop ourselves,
      for good reason, either because we cannot afford to fork, or we are
      very much displeased at the idea. I have a fork of JSLint and it's
      really annoying. In fact, it's gotten to the point where I'm kind of
      afraid to update it because of what it might bring.

      --jhawk@...
      John Hawkinson
    • mathew
      ... Someone else already suggested running a beautifier on the code. Here are three more solutions: 1. Have the unit tests run an EOL whitespace check. 2. Have
      Message 2 of 22 , Nov 14, 2011
      • 0 Attachment
        >
        > - Trailing whitespace and whitespace on blank lines is not allowed. Again,
        > my product consists of thousands of lines of JavaScript which are updated
        > daily by developers using an editor that doesn't strip trailing whitespace
        > by default.


        Someone else already suggested running a beautifier on the code. Here are
        three more solutions:

        1. Have the unit tests run an EOL whitespace check.

        2. Have a pre-commit hook in your version control system that checks for
        EOL whitespace and abandons the commit if it finds any.

        With those two approaches, developers will either learn to configure their
        text editors, or put up with the annoyance of fixing the files manually
        whenever they cause an error. If that's not acceptable for some reason,
        then:

        3. Have a pre-commit hook that strips EOL whitespace from the JavaScript
        for them.

        In fact, you could use jslint itself as a pre-commit hook, could you not?
        https://github.com/jrburke/dvcs_jslint/


        mathew
        --
        <URL:http://www.pobox.com/~meta/>


        [Non-text portions of this message have been removed]
      • John Hawkinson
        ... ... These solutions may be reasonable if you are just starting out. They are not reasonable if you have a large installed codebase. Guess which position
        Message 3 of 22 , Nov 14, 2011
        • 0 Attachment
          mathew <meta404@...> wrote on Mon, 14 Nov 2011 at 13:23:24 -0600:

          > Someone else already suggested running a beautifier on the code. Here are
          > three more solutions:
          ...

          These solutions may be reasonable if you are just starting out.
          They are not reasonable if you have a large installed codebase.
          Guess which position most jslint users are in?

          --jhawk@...
          John Hawkinson
        • mathew
          ... So don t run JSLint on your entire codebase. Either you need to fix the problems in the code that cause JSLint failures, or you need to not run JSLint on
          Message 4 of 22 , Nov 14, 2011
          • 0 Attachment
            >
            > These solutions may be reasonable if you are just starting out.
            > They are not reasonable if you have a large installed codebase.


            So don't run JSLint on your entire codebase.

            Either you need to fix the problems in the code that cause JSLint failures,
            or you need to not run JSLint on the code. Having JSLint fail to report
            problems because you don't have time to fix the code is not a sensible
            option. If it was, we could just replace JSLint with a no-op.


            mathew
            --
            <URL:http://www.pobox.com/~meta/>


            [Non-text portions of this message have been removed]
          • Erik Eckhardt
            Matthew, By saying fix the code you are saying the code is broken. Except, trailing white space is *not* broken code in the minds of many users, as evidenced
            Message 5 of 22 , Nov 14, 2011
            • 0 Attachment
              Matthew,

              By saying "fix the code" you are saying the code is broken. Except,
              trailing white space is *not* broken code in the minds of many users, as
              evidenced by all the discussion on this topic. You're ignoring this and
              instead treating jslint's demands as some automatic canonical standard,
              which failing to meet proves the code is broken, problematic, or otherwise
              less than perfect or ideal.

              So, please stop arguing for and discussing the wrong thing. It is *not* a
              logistical problem of how to conform with jslint. They're programmers. They
              can probably figure this out if they really have the inclination and all
              other avenues are blocked. The issue is that for certain legitimate issues,
              jslint should offer the flexibility for people to clean their code the way
              they want, without the unnecessary pain caused by overzealous restrictions
              in an otherwise very valuable tool.

              Who is jslint for? Who is the customer? Why is it being produced? What is
              its actual purpose? Does the owner care if some portion of the user base is
              alienated by unnanounced beraking changes? If we had these things clearly
              stated, perhaps some of the customers might decide not to be so any more.
              If the expectation is that jslint can and will be changed without notice in
              a way that breaks actual money-making operations (that is, the day-to-day
              business need of users to produce code without unneeded & costly roadblocks
              randomly showing up), perhaps it is too risky to integrate it into our
              businesses. Wait... we can just use an old version, right? Unless we find
              some other tool that is also growing but doesn't have the same risks...

              Erik

              On Mon, Nov 14, 2011 at 11:32 AM, mathew <meta404@...> wrote:

              > **
              >
              >
              > >
              > > These solutions may be reasonable if you are just starting out.
              > > They are not reasonable if you have a large installed codebase.
              >
              > So don't run JSLint on your entire codebase.
              >
              > Either you need to fix the problems in the code that cause JSLint failures,
              > or you need to not run JSLint on the code. Having JSLint fail to report
              > problems because you don't have time to fix the code is not a sensible
              > option. If it was, we could just replace JSLint with a no-op.
              >
              >
              > mathew
              > --
              > <URL:http://www.pobox.com/~meta/>
              >
              > [Non-text portions of this message have been removed]
              >
              >
              >


              [Non-text portions of this message have been removed]
            • douglascrockford
              ... JSLint was written for me. JavaScript is a language full of traps and sharp edges. I do not dare write in JavaScript without JSLint s assistance. I have
              Message 6 of 22 , Nov 14, 2011
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:

                > Who is jslint for? Who is the customer? Why is it being produced? What is
                > its actual purpose? Does the owner care if some portion of the user base is
                > alienated by unnanounced beraking changes? If we had these things clearly
                > stated, perhaps some of the customers might decide not to be so any more.
                > If the expectation is that jslint can and will be changed without notice in
                > a way that breaks actual money-making operations (that is, the day-to-day
                > business need of users to produce code without unneeded & costly roadblocks
                > randomly showing up), perhaps it is too risky to integrate it into our
                > businesses. Wait... we can just use an old version, right? Unless we find
                > some other tool that is also growing but doesn't have the same risks...


                JSLint was written for me. JavaScript is a language full of traps and sharp edges. I do not dare write in JavaScript without JSLint's assistance. I have made it available to the world for free. If it helps you too, then great. If it doesn't help you, then don't use it. I get paid the same either way.

                I have been improving JSLint with the assistance of the people who use it. As our understanding of the hazards in JavaScript improve, JSLint improves, and the subset of JavaScript that it recommends changes.

                Regrettably, this necessarily causes programs with previously undiscovered faults to, as you would say, berak. When that happens, the best advice is to follow JSLint's advice and fix your code.

                With respect to spaces at the end of lines: From a code hygiene perspective, there is no good argument for keeping them. If you are arguing that there is no one in your organization with the programming skill to remove them, then it seems your organization is suffering from problems that JSLint cannot help you solve. But in any case, the "Tolerate messy white space" option will ignore those spaces. But my advice is to not use that option and write smart looking code instead.
              • paulcrowder1979
                ... I agree with some of your points. JSLint is a valuable tool, and I do not write JavaScript without it. I also see the value in adding new rules as new
                Message 7 of 22 , Nov 16, 2011
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
                  >
                  > JSLint was written for me. JavaScript is a language full of traps and sharp edges. I do not dare write in JavaScript without JSLint's assistance. I have made it available to the world for free. If it helps you too, then great. If it doesn't help you, then don't use it. I get paid the same either way.
                  >
                  > I have been improving JSLint with the assistance of the people who use it. As our understanding of the hazards in JavaScript improve, JSLint improves, and the subset of JavaScript that it recommends changes.
                  >
                  > Regrettably, this necessarily causes programs with previously undiscovered faults to, as you would say, berak. When that happens, the best advice is to follow JSLint's advice and fix your code.
                  >
                  > With respect to spaces at the end of lines: From a code hygiene perspective, there is no good argument for keeping them. If you are arguing that there is no one in your organization with the programming skill to remove them, then it seems your organization is suffering from problems that JSLint cannot help you solve. But in any case, the "Tolerate messy white space" option will ignore those spaces. But my advice is to not use that option and write smart looking code instead.
                  >

                  I agree with some of your points. JSLint is a valuable tool, and I do not write JavaScript without it. I also see the value in adding new rules as new hazards are discovered. What I don't understand is adding arbitrary rules that don't add to the quality of the code. You say there's no argument for keeping trailing whitespace, but I disagree. The best argument is that the whitespace is already there, it's doing no harm, and to remove it and enforce that all new code not have it would require a non-trivial amount of effort. That is effort that could be spent adding to the quality of our product, such as adding new features and fixing real bugs, rather than fiddling with code (wasn't it you who said "I highly recommend you don't fiddle with code"? https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5). I'm not sure why you jumped to the conclusion that no one in my organization has the skill to write a utility to remove trailing whitespace rather than perhaps considering the fact that writing the utility costs time and money; I think that says more about you than it does my organization.
                • Michael Mikowski
                  Removing trailing whitespace IS trivial: sed -i -e s/ s*$// $(find ./ -type f) Of course if you are using notepad, it might take a few months.
                  Message 8 of 22 , Nov 16, 2011
                  • 0 Attachment
                    Removing trailing whitespace IS trivial:

                    sed -i -e 's/\s*$//' $(find ./ -type f)


                    Of course if you are using notepad, it might take a few months.



                    ________________________________
                    From: paulcrowder1979 <paul@...>
                    To: jslint_com@yahoogroups.com
                    Sent: Wednesday, November 16, 2011 12:44 PM
                    Subject: [jslint] Re: Can we please lose the trailing whitespace and "this" restriction?


                     


                    --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
                    >
                    > JSLint was written for me. JavaScript is a language full of traps and sharp edges. I do not dare write in JavaScript without JSLint's assistance. I have made it available to the world for free. If it helps you too, then great. If it doesn't help you, then don't use it. I get paid the same either way.
                    >
                    > I have been improving JSLint with the assistance of the people who use it. As our understanding of the hazards in JavaScript improve, JSLint improves, and the subset of JavaScript that it recommends changes.
                    >
                    > Regrettably, this necessarily causes programs with previously undiscovered faults to, as you would say, berak. When that happens, the best advice is to follow JSLint's advice and fix your code.
                    >
                    > With respect to spaces at the end of lines: From a code hygiene perspective, there is no good argument for keeping them. If you are arguing that there is no one in your organization with the programming skill to remove them, then it seems your organization is suffering from problems that JSLint cannot help you solve. But in any case, the "Tolerate messy white space" option will ignore those spaces. But my advice is to not use that option and write smart looking code instead.
                    >

                    I agree with some of your points. JSLint is a valuable tool, and I do not write JavaScript without it. I also see the value in adding new rules as new hazards are discovered. What I don't understand is adding arbitrary rules that don't add to the quality of the code. You say there's no argument for keeping trailing whitespace, but I disagree. The best argument is that the whitespace is already there, it's doing no harm, and to remove it and enforce that all new code not have it would require a non-trivial amount of effort. That is effort that could be spent adding to the quality of our product, such as adding new features and fixing real bugs, rather than fiddling with code (wasn't it you who said "I highly recommend you don't fiddle with code"? https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5). I'm not sure why you jumped to the conclusion that no one in my organization has the skill to write a utility to remove trailing whitespace
                    rather than perhaps considering the fact that writing the utility costs time and money; I think that says more about you than it does my organization.




                    [Non-text portions of this message have been removed]
                  • Michael Mikowski
                    You want to do this independent of all other code work.  So the following workflow is recommended: git pull sed -i -e s/ s*$// $(find ./ -type f) // ensure
                    Message 9 of 22 , Nov 16, 2011
                    • 0 Attachment
                      You want to do this independent of all other code work.  So the following workflow is recommended:

                      git pull
                      sed -i -e 's/\s*$//' $(find ./ -type f)
                      // ensure nothing has been broken (run your executable against regression tests!):
                      git diff
                      git difftool

                      // and now save the changes ye hath wrought:
                      git commit -a -m 'Removed trailing whitespace in all files in repo'


                      ________________________________
                      From: Michael Mikowski <z_mikowski@...>
                      To: "jslint_com@yahoogroups.com" <jslint_com@yahoogroups.com>
                      Cc: paulcrowder1979 <paul@...>
                      Sent: Wednesday, November 16, 2011 1:27 PM
                      Subject: Re: [jslint] Re: Can we please lose the trailing whitespace and "this" restriction?


                      Removing trailing whitespace IS trivial:

                      sed -i -e 's/\s*$//' $(find ./ -type f)


                      Of course if you are using notepad, it might take a few months.



                      ________________________________
                      From: paulcrowder1979 <paul@...>
                      To: jslint_com@yahoogroups.com
                      Sent: Wednesday, November 16, 2011 12:44 PM
                      Subject: [jslint] Re: Can we please lose the trailing whitespace and "this" restriction?


                       


                      --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
                      >
                      > JSLint was written for me. JavaScript is a language full of traps and sharp edges. I do not dare write in JavaScript without JSLint's assistance. I have made it available to the world for free. If it helps you too, then great. If it doesn't help you, then don't use it. I get paid the same either way.
                      >
                      > I have been improving JSLint with the assistance of the people who use it. As our understanding of the hazards in JavaScript improve, JSLint improves, and the subset of JavaScript that it recommends changes.
                      >
                      > Regrettably, this necessarily causes programs with previously undiscovered faults to, as you would say, berak. When that happens, the best advice is to follow JSLint's advice and fix your code.
                      >
                      > With respect to spaces at the end of lines: From a code hygiene perspective, there is no good argument for keeping them. If you are arguing that there is no one in your organization with the programming skill to remove them, then it seems your organization is suffering from problems that JSLint cannot help you solve. But in any case, the "Tolerate messy white space" option will ignore those spaces. But my advice is to not use that option and write smart looking code instead.
                      >

                      I agree with some of your points. JSLint is a valuable tool, and I do not write JavaScript without it. I also see the value in adding new rules as new hazards are discovered. What I don't understand is adding arbitrary rules that don't add to the quality of the code. You say there's no argument for keeping trailing whitespace, but I disagree. The best argument is that the whitespace is already there, it's doing no harm, and to remove it and enforce that all new code not have it would require a non-trivial amount of effort. That is effort that could be spent adding to the quality of our product, such as adding new features and fixing real bugs, rather than fiddling with code (wasn't it you who said "I highly recommend you don't fiddle with code"? https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5). I'm not sure why you jumped to the conclusion that no one in my organization has the skill to write a utility to remove trailing whitespace
                      rather than perhaps considering the fact that writing the utility costs time and money; I think that says more about you than it does my organization.




                      [Non-text portions of this message have been removed]
                    • paulcrowder1979
                      ... Writing the code is trivial. Pushing out an IDE plug-in to 100+ developers that will run the code when they save their files, waiting for the plug-in to
                      Message 10 of 22 , Nov 17, 2011
                      • 0 Attachment
                        --- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                        >
                        > Removing trailing whitespace IS trivial:
                        >
                        > sed -i -e 's/\s*$//' $(find ./ -type f)
                        >
                        >
                        > Of course if you are using notepad, it might take a few months.
                        >

                        Writing the code is trivial. Pushing out an IDE plug-in to 100+ developers that will run the code when they save their files, waiting for the plug-in to propagate to every developer, then updating our check-in policy to enforce the new rule is not trivial. I don't mind going through that effort when the pay-off is significant, but removing trailing whitespace has zero impact on the shipping product so it's not worth the effort.

                        It looks like my only recourse at this point is to rip out the two lines of JSLint that enforce the trailing whitespace rule and the "this" strict violation rule each time I upgrade JSLint. I actually have more of a problem with the "this" restriction for reasons I mentioned earlier, but I have no confidence that it will be addressed after having read the opinion of his users that Douglas Crockford stated in his previous post.
                      • Michael Mikowski
                        Hey Paul: I feel your pain.  I don t know your process, environment, and restrictions.  So all this is speculation. If you are supporting 100+ developers,
                        Message 11 of 22 , Nov 17, 2011
                        • 0 Attachment
                          Hey Paul:

                          I feel your pain.  I don't know your process, environment, and restrictions.  So all this is speculation.

                          If you are supporting 100+ developers, you certainly seem to have the critical mass to justify creating a forked version for your purposes.  You could then distribute to the developers via your SCMS, and using it in your build process.  Our official JSLint utility is kept in SCMS, and changes about once per quarter.  It is almost always adjusted to meet our standards that deviate from the JSLint way.

                          I am very happy with that solution, and am very greatfull that I don't have to write 99% of our Lint utility, and that Mr. Crockford is kind enough to share this wonderful software with us, even if his idea of well formatted code doesn't agree with mine :)

                          Sincerely, Mike

                          ps here is my vim "plugin" for removing whitespace:

                          "=====[ ;removes trailing space ]=====

                          map ;k :%s?\s\+$??<CR>
                           
                          pss

                          If you wanted to enforce no-trailing-whitespace, you could update your entire repository as below, check-in, and then make developers aware that trailing whitespace will no longer be acceptable under JSLint.



                          ________________________________
                          From: paulcrowder1979 <paul@...>
                          To: jslint_com@yahoogroups.com
                          Sent: Thursday, November 17, 2011 7:31 AM
                          Subject: [jslint] Re: Can we please lose the trailing whitespace and "this" restriction?


                           


                          --- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                          >
                          > Removing trailing whitespace IS trivial:
                          >
                          > sed -i -e 's/\s*$//' $(find ./ -type f)
                          >
                          >
                          > Of course if you are using notepad, it might take a few months.
                          >

                          Writing the code is trivial. Pushing out an IDE plug-in to 100+ developers that will run the code when they save their files, waiting for the plug-in to propagate to every developer, then updating our check-in policy to enforce the new rule is not trivial. I don't mind going through that effort when the pay-off is significant, but removing trailing whitespace has zero impact on the shipping product so it's not worth the effort.

                          It looks like my only recourse at this point is to rip out the two lines of JSLint that enforce the trailing whitespace rule and the "this" strict violation rule each time I upgrade JSLint. I actually have more of a problem with the "this" restriction for reasons I mentioned earlier, but I have no confidence that it will be addressed after having read the opinion of his users that Douglas Crockford stated in his previous post.




                          [Non-text portions of this message have been removed]
                        • Jean-Charles Meyrignac
                          ... In my company, we use SVN+CCNet+Nant/MsBuild If you have 100+ developers, you necessarily have a continuous build, and I m 100% sure that you can script
                          Message 12 of 22 , Nov 17, 2011
                          • 0 Attachment
                            On Thu, Nov 17, 2011 at 11:48 PM, Michael Mikowski <z_mikowski@...>wrote:

                            > **
                            >
                            >
                            > Our official JSLint utility is kept in SCMS, and changes about once per
                            > quarter. It is almost always adjusted to meet our standards that deviate
                            > from the JSLint way.
                            >
                            > +1
                            In my company, we use SVN+CCNet+Nant/MsBuild

                            If you have 100+ developers, you necessarily have a continuous build, and
                            I'm 100% sure that you can script your own build automation.
                            When people commit their source, the source could be automatically cleaned
                            (or you can clean it once, and force the developers to follow the rules).
                            Then, your build process should parse JS sources with JSLint, and block the
                            build if there are errors.
                            The goal of breaking the build is to force developers to acquire good
                            programming habits. It's very difficult to change habits, because nobody
                            wants to follow new rules.
                            Once the sources have been checked against your coding rules, the process
                            should run some unit tests, to validate that the basic functions are not
                            broken.

                            I agree that this solution is quite "brute", but you should see JsLint as
                            an ally instead of an enemy.
                            Personally, I tended to fight against software until I stopped trying to
                            force my wishes on it, and everything went smoothly afterwards.

                            Alternatively, you can use a modified version of JsLint in your build
                            process, and upgrade your local version every 6 months, as the parent post
                            explained.

                            JC


                            [Non-text portions of this message have been removed]
                          • Nagy Endre
                            Hi everyone, maybe it s a little offtopic sorry, but can anyone explain why this inside the o object is refer to window ? Why it s not refer to the o
                            Message 13 of 22 , Nov 18, 2011
                            • 0 Attachment
                              Hi everyone, maybe it's a little offtopic sorry, but can anyone explain why "this" inside the "o" object is refer to window ?
                              Why it's not refer to the "o" object if we are inside there? I want to access from the returned object in function "f" the "o.p" property without using "o". Thanks!

                              var p = 2,
                                  o  =  {
                                      p: "a",
                                      f: (function (m) {
                                          return {
                                              l: m.p
                                          };
                                      }(this))
                                  };

                              p = o.f.l;

                              Endre


                              [Non-text portions of this message have been removed]
                            • z_mikowski@yahoo.com
                              Javascript does not provide block scope, only functional scope. Therefore the this in your code takes the value as provided to the enclosing function. You
                              Message 14 of 22 , Nov 18, 2011
                              • 0 Attachment
                                Javascript does not provide block scope, only functional scope. Therefore the 'this' in your code takes the value as provided to the enclosing function. You could use the module pattern to get the results you are seeking, e.g.

                                var o = function (){
                                // private stuff
                                return {
                                p : "a",
                                // rest of object here
                                };
                                };



                                Nagy Endre <forewer2000@...> wrote:

                                >
                                >Hi everyone, maybe it's a little offtopic sorry, but can anyone explain why "this" inside the "o" object is refer to window ?
                                >Why it's not refer to the "o" object if we are inside there? I want to access from the returned object in function "f" the "o.p" property without using "o". Thanks!
                                >
                                >var p = 2,
                                >    o  =  {
                                >        p: "a",
                                >        f: (function (m) {
                                >            return {
                                >                l: m.p
                                >            };
                                >        }(this))
                                >    };
                                >
                                >p = o.f.l;
                                >
                                >Endre
                                >
                                >
                                >[Non-text portions of this message have been removed]
                                >


                                [Non-text portions of this message have been removed]
                              • Rob Richardson
                                Try this: var p = 2, o = { p: a }; o.f = (function (m) { return { l: m.p }; }(o)); p = o.f.l; Or this: var p = 2, o = { p: a }; o.prototype.f =
                                Message 15 of 22 , Nov 18, 2011
                                • 0 Attachment
                                  Try this:

                                  var p = 2,
                                  o = {
                                  p: "a"
                                  };
                                  o.f = (function (m) {
                                  return {
                                  l: m.p
                                  };
                                  }(o));
                                  p = o.f.l;

                                  Or this:

                                  var p = 2,
                                  o = {
                                  p: "a"
                                  };
                                  o.prototype.f = function () {
                                  return {
                                  l: this.p
                                  };
                                  };
                                  p = o.f.l;

                                  Rob


                                  -----Original Message-----
                                  From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
                                  Behalf Of Nagy Endre
                                  Sent: Friday, November 18, 2011 7:13 AM
                                  To: jslint_com@yahoogroups.com
                                  Subject: [jslint] this question




                                  Hi everyone, maybe it's a little offtopic sorry, but can anyone explain why
                                  "this" inside the "o" object is refer to window ?
                                  Why it's not refer to the "o" object if we are inside there? I want to
                                  access from the returned object in function "f" the "o.p" property without
                                  using "o". Thanks!

                                  var p = 2,
                                  o = {
                                  p: "a",
                                  f: (function (m) {
                                  return {
                                  l: m.p
                                  };
                                  }(this))
                                  };

                                  p = o.f.l;

                                  Endre

                                  [Non-text portions of this message have been removed]
                                • stauren
                                  I don t think this is about block scope or functional sope. This is probably because the function is executed when the script is being parsed, at which time
                                  Message 16 of 22 , Nov 20, 2011
                                  • 0 Attachment
                                    I don't think this is about block scope or functional sope. This is
                                    probably because the function is executed when the script is being parsed,
                                    at which time the outer object is not fully established, so the the keyword
                                    'this' points to the window object.

                                    Another funny aspect of javascript.

                                    ---
                                    stauren (畅)
                                    blog : http://stauren.net
                                    email : stauren@...


                                    On Sat, Nov 19, 2011 at 12:19 AM, <z_mikowski@...> wrote:

                                    > **
                                    >
                                    >
                                    > Javascript does not provide block scope, only functional scope. Therefore
                                    > the 'this' in your code takes the value as provided to the enclosing
                                    > function. You could use the module pattern to get the results you are
                                    > seeking, e.g.
                                    >
                                    > var o = function (){
                                    > // private stuff
                                    > return {
                                    > p : "a",
                                    > // rest of object here
                                    > };
                                    > };
                                    >
                                    >
                                    > Nagy Endre <forewer2000@...> wrote:
                                    >
                                    > >
                                    > >Hi everyone, maybe it's a little offtopic sorry, but can anyone explain
                                    > why "this" inside the "o" object is refer to window ?
                                    > >Why it's not refer to the "o" object if we are inside there? I want to
                                    > access from the returned object in function "f" the "o.p" property without
                                    > using "o". Thanks!
                                    > >
                                    > >var p = 2,
                                    > > o = {
                                    > > p: "a",
                                    > > f: (function (m) {
                                    > > return {
                                    > > l: m.p
                                    > > };
                                    > > }(this))
                                    > > };
                                    > >
                                    > >p = o.f.l;
                                    > >
                                    > >Endre
                                    > >
                                    > >
                                    > >[Non-text portions of this message have been removed]
                                    > >
                                    >
                                    > [Non-text portions of this message have been removed]
                                    >
                                    >
                                    >


                                    [Non-text portions of this message have been removed]
                                  • Nagy Endre
                                    Yes, i realized that in {a: this} the value of a is the window value, not what we expect, because at runtime probably the object is not created yet, so
                                    Message 17 of 22 , Nov 21, 2011
                                    • 0 Attachment
                                      Yes, i realized that in {a: this} the value of "a" is the "window" value, not what we expect, because at runtime probably the object is not created yet,
                                      so only a method that is called later could have the correct "this" value.

                                      I think it would be great if JSLINT could display an error in this situation like:
                                      var o = {
                                          a : this;
                                      };

                                      Because i think is there a little confusion here what will be the value of "this".



                                      ________________________________
                                      From: stauren <liuch.pku@...>
                                      To: jslint_com@yahoogroups.com
                                      Sent: Monday, November 21, 2011 9:49 AM
                                      Subject: Re: [jslint] this question


                                       
                                      I don't think this is about block scope or functional sope. This is
                                      probably because the function is executed when the script is being parsed,
                                      at which time the outer object is not fully established, so the the keyword
                                      'this' points to the window object.

                                      Another funny aspect of javascript.

                                      ---
                                      stauren (畅)
                                      blog : http://stauren.net
                                      email : stauren@...

                                      On Sat, Nov 19, 2011 at 12:19 AM, <z_mikowski@...> wrote:

                                      > **
                                      >
                                      >
                                      > Javascript does not provide block scope, only functional scope. Therefore
                                      > the 'this' in your code takes the value as provided to the enclosing
                                      > function. You could use the module pattern to get the results you are
                                      > seeking, e.g.
                                      >
                                      > var o = function (){
                                      > // private stuff
                                      > return {
                                      > p : "a",
                                      > // rest of object here
                                      > };
                                      > };
                                      >
                                      >
                                      > Nagy Endre <forewer2000@...> wrote:
                                      >
                                      > >
                                      > >Hi everyone, maybe it's a little offtopic sorry, but can anyone explain
                                      > why "this" inside the "o" object is refer to window ?
                                      > >Why it's not refer to the "o" object if we are inside there? I want to
                                      > access from the returned object in function "f" the "o.p" property without
                                      > using "o". Thanks!
                                      > >
                                      > >var p = 2,
                                      > > o = {
                                      > > p: "a",
                                      > > f: (function (m) {
                                      > > return {
                                      > > l: m.p
                                      > > };
                                      > > }(this))
                                      > > };
                                      > >
                                      > >p = o.f.l;
                                      > >
                                      > >Endre
                                      > >
                                      > >
                                      > >[Non-text portions of this message have been removed]
                                      > >
                                      >
                                      > [Non-text portions of this message have been removed]
                                      >
                                      >
                                      >

                                      [Non-text portions of this message have been removed]




                                      [Non-text portions of this message have been removed]
                                    Your message has been successfully submitted and would be delivered to recipients shortly.