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

Why disallow new as statement?

Expand Messages
  • Satyam
    When I don t actually need the object instance, I enclose my new Xxxx() statements in parenthesis to keep JSLint happy and I assumed some JavaScript
    Message 1 of 7 , Feb 20, 2010
    • 0 Attachment
      When I don't actually need the object instance, I enclose my "new
      Xxxx()" statements in parenthesis to keep JSLint happy and I assumed
      some JavaScript interpreter might get lost with such a statement but it
      doesn't seem to happen. The JSLint site paragraph about the use of
      Constructors and new does not mention why this is not valid either.

      Something that really surprises me is that JSLint simply quits on
      finding one of this. May I assume that it is a limitation of the
      parser used in JSLint and it really has nothing to do with JavaScript
      itself?

      The issue came when I was writing a piece of code for publication and I
      did the parenthesis trick and found myself having no good explanation
      for that. (I might have assigned to a variable, but then I would have
      gotten another warning from JSLint).

      Thanks
      Satyam
    • Douglas Crockford
      ... Thanks for pointing that out. JSLint now warns when new is wrapped in parens to avoid a warning. I don t recommend the use of new . I think it is one of
      Message 2 of 7 , Feb 20, 2010
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
        >
        > When I don't actually need the object instance, I enclose my "new
        > Xxxx()" statements in parenthesis to keep JSLint happy and I assumed
        > some JavaScript interpreter might get lost with such a statement but it
        > doesn't seem to happen. The JSLint site paragraph about the use of
        > Constructors and new does not mention why this is not valid either.


        Thanks for pointing that out. JSLint now warns when new is wrapped in parens to avoid a warning.

        I don't recommend the use of 'new'. I think it is one of the bad parts. But it is popular for object creation so JSLint tolerates it, but enforces the capitalization convention to avoid the biggest problems.

        There is no excuse for using it for side effects, so JSLint warns for that.
      • Satyam
        ... The purpose of that instance (YUI2 DDTarget) is for it to register itself in a static array (somewhere in DragDropMgr) so, yes, I create it for a side
        Message 3 of 7 , Feb 21, 2010
        • 0 Attachment
          El 21/02/2010 0:24, Douglas Crockford escribió:
          >
          > --- In jslint_com@yahoogroups.com
          > <mailto:jslint_com%40yahoogroups.com>, Satyam <satyam@...> wrote:
          > >
          > > When I don't actually need the object instance, I enclose my "new
          > > Xxxx()" statements in parenthesis to keep JSLint happy and I assumed
          > > some JavaScript interpreter might get lost with such a statement but it
          > > doesn't seem to happen. The JSLint site paragraph about the use of
          > > Constructors and new does not mention why this is not valid either.
          >
          > Thanks for pointing that out. JSLint now warns when new is wrapped in
          > parens to avoid a warning.
          >
          > I don't recommend the use of 'new'. I think it is one of the bad
          > parts. But it is popular for object creation so JSLint tolerates it,
          > but enforces the capitalization convention to avoid the biggest problems.
          >
          > There is no excuse for using it for side effects, so JSLint warns for
          > that.
          >
          The purpose of that instance (YUI2 DDTarget) is for it to register
          itself in a static array (somewhere in DragDropMgr) so, yes, I create it
          for a side effect, but that is how the library is built and have no
          control over that (nor is a regular user expected to even know that this
          is what is happening). It makes sense for DDTarget to be an object
          because sometimes you do have other things to do with it and you need a
          reference to that instance, but not always. I don't assume that would
          happen in YUI3, but YUI2 is like that and it is not going to change so I
          have only these choices left:

          a) Create the instance and assign it to a variable which will be marked
          unused since there is really nothing I could possibly do with it
          b) Create the instance and have a warning that I'm using new as a statement
          c) Enclose that in parenthesis and, now, have another warning

          So, in any of the cases I would have a warning and there is nothing I
          could possibly do to avoid it because that is how the library is used,
          and I have no control about that.

          As I said, I can live with that as I could live with the parenthesis but
          the problem is, how do I explain that in the article? It would become
          harder to recommend JSlint to a newcomer if you have to qualify your
          recommendation with 'ignore this warning' and 'ignore that warning'.
          JSLint already tolerates (optionally) far worst practices than this
          one. It should offer an option for this one. YUI2 won't change in
          order to preserve backward compatibility, that is why the YUI3 line was
          started. If JSLint keeps evolving it will veer so far apart from YUI2
          that it will become harder to recommend, which would be a pity.

          Satyam

          It should also document why it doesn't like it.


          [Non-text portions of this message have been removed]
        • James Clark
          ... How about this: function register_ddtarget(...) { return new DDTarget(...); } register_ddtarget(...); -jamie
          Message 4 of 7 , Feb 21, 2010
          • 0 Attachment
            On 2/21/2010 4:35 AM, Satyam wrote:
            > The purpose of that instance (YUI2 DDTarget) is for it to register
            > itself in a static array (somewhere in DragDropMgr) so, yes, I create it
            > for a side effect, but that is how the library is built and have no
            > control over that (nor is a regular user expected to even know that this

            How about this:

            function register_ddtarget(...) {
            return new DDTarget(...);
            }

            register_ddtarget(...);

            -jamie
          • Satyam
            Thanks, James, but how to fool JSLint is not the question but why does it need to be fooled at all is. I use and recommend JSLint constantly and the first
            Message 5 of 7 , Feb 21, 2010
            • 0 Attachment
              Thanks, James, but how to fool JSLint is not the question but why does
              it need to be fooled at all is.

              I use and recommend JSLint constantly and the first thing I check when I
              have some problem with my code is give it a try, and never release
              something if JSLint doesn't give it a clean bill of health, and I
              suggest the same to others. I can't change the YUI library, and I agree
              that I shouldn't because backward compatibility is important, so, I have
              to live with it. But now, I have to accept that my code has to be
              ninety-X percent compliant with JSLint, because JSLint will complain
              about things I can do nothing about. And I have to go and read those
              errors. Not just checking whether I get the panel with the redish
              background or not, I know my YAHOO widget will never give me an Ok and I
              will have to go through the trouble of checking which errors are there
              and which aren't, which takes time.

              Worst, I cannot blindly recommend JSLint to newcomers telling them to
              really try and get a 100% error free JSLint pass simply because I know
              it is not going to happen and giving such recommendation will get people
              coming back to me asking why is it complaining about this or about that,
              if it works. What am I going to say: fool JSLint? That's not the
              answer. The point of the game is to get good code, not code that fools
              JSLint.

              What's a manager to do? You could put in the rules that all code should
              go through JSLint and the HTMLValidator. 100% valid in both cases.
              Easy. Now, you have to add a list of exceptions to that 100%. Not a
              good thing. Harder to manage, easier to cheat. If you start fooling
              JSLint to get a clean bill of health you have to cheat, and when you get
              your team to start cheating, there is no end to that cheating, all code
              becomes suspect. And the fact is, YUI2 is there.

              Satyam
            • Arthur Blake
              This issue irritates me too. I use JSLint religiously, but I have to fool it to make it pass with some of my YUI code-- I would have thought that Doug would
              Message 6 of 7 , Feb 21, 2010
              • 0 Attachment
                This issue irritates me too. I use JSLint religiously, but I have to fool
                it to make it pass with some of my YUI code-- I would have thought that Doug
                would have "convinced" the YUI team to follow these rules...

                On Sun, Feb 21, 2010 at 1:56 PM, Satyam <satyam@...> wrote:

                >
                >
                > Thanks, James, but how to fool JSLint is not the question but why does
                > it need to be fooled at all is.
                >
                > I use and recommend JSLint constantly and the first thing I check when I
                > have some problem with my code is give it a try, and never release
                > something if JSLint doesn't give it a clean bill of health, and I
                > suggest the same to others. I can't change the YUI library, and I agree
                > that I shouldn't because backward compatibility is important, so, I have
                > to live with it. But now, I have to accept that my code has to be
                > ninety-X percent compliant with JSLint, because JSLint will complain
                > about things I can do nothing about. And I have to go and read those
                > errors. Not just checking whether I get the panel with the redish
                > background or not, I know my YAHOO widget will never give me an Ok and I
                > will have to go through the trouble of checking which errors are there
                > and which aren't, which takes time.
                >
                > Worst, I cannot blindly recommend JSLint to newcomers telling them to
                > really try and get a 100% error free JSLint pass simply because I know
                > it is not going to happen and giving such recommendation will get people
                > coming back to me asking why is it complaining about this or about that,
                > if it works. What am I going to say: fool JSLint? That's not the
                > answer. The point of the game is to get good code, not code that fools
                > JSLint.
                >
                > What's a manager to do? You could put in the rules that all code should
                > go through JSLint and the HTMLValidator. 100% valid in both cases.
                > Easy. Now, you have to add a list of exceptions to that 100%. Not a
                > good thing. Harder to manage, easier to cheat. If you start fooling
                > JSLint to get a clean bill of health you have to cheat, and when you get
                > your team to start cheating, there is no end to that cheating, all code
                > becomes suspect. And the fact is, YUI2 is there.
                >
                > Satyam
                >
                >


                [Non-text portions of this message have been removed]
              • Satyam
                YUI2 has plenty of issues and they won t be fixed because that would mean breaking plenty of existing applications. That is one of the reasons to start YUI3,
                Message 7 of 7 , Feb 22, 2010
                • 0 Attachment
                  YUI2 has plenty of issues and they won't be fixed because that would
                  mean breaking plenty of existing applications. That is one of the
                  reasons to start YUI3, to make a clean break and make it good. YUI2
                  will forever have some issues because its public interfaces are
                  frozen. It is not that the YUI team has not learned anything over
                  these years, in fact, you can see a big evolution in the components over
                  time, but all those lessons cannot go into the older components of YUI2.


                  El 22/02/2010 3:22, Arthur Blake escribió:
                  > This issue irritates me too. I use JSLint religiously, but I have to fool
                  > it to make it pass with some of my YUI code-- I would have thought that Doug
                  > would have "convinced" the YUI team to follow these rules...
                  >
                  > On Sun, Feb 21, 2010 at 1:56 PM, Satyam<satyam@...> wrote:
                  >
                  >
                  >>
                  >> Thanks, James, but how to fool JSLint is not the question but why does
                  >> it need to be fooled at all is.
                  >>
                  >> I use and recommend JSLint constantly and the first thing I check when I
                  >> have some problem with my code is give it a try, and never release
                  >> something if JSLint doesn't give it a clean bill of health, and I
                  >> suggest the same to others. I can't change the YUI library, and I agree
                  >> that I shouldn't because backward compatibility is important, so, I have
                  >> to live with it. But now, I have to accept that my code has to be
                  >> ninety-X percent compliant with JSLint, because JSLint will complain
                  >> about things I can do nothing about. And I have to go and read those
                  >> errors. Not just checking whether I get the panel with the redish
                  >> background or not, I know my YAHOO widget will never give me an Ok and I
                  >> will have to go through the trouble of checking which errors are there
                  >> and which aren't, which takes time.
                  >>
                  >> Worst, I cannot blindly recommend JSLint to newcomers telling them to
                  >> really try and get a 100% error free JSLint pass simply because I know
                  >> it is not going to happen and giving such recommendation will get people
                  >> coming back to me asking why is it complaining about this or about that,
                  >> if it works. What am I going to say: fool JSLint? That's not the
                  >> answer. The point of the game is to get good code, not code that fools
                  >> JSLint.
                  >>
                  >> What's a manager to do? You could put in the rules that all code should
                  >> go through JSLint and the HTMLValidator. 100% valid in both cases.
                  >> Easy. Now, you have to add a list of exceptions to that 100%. Not a
                  >> good thing. Harder to manage, easier to cheat. If you start fooling
                  >> JSLint to get a clean bill of health you have to cheat, and when you get
                  >> your team to start cheating, there is no end to that cheating, all code
                  >> becomes suspect. And the fact is, YUI2 is there.
                  >>
                  >> Satyam
                  >>
                  >>
                  >>
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  > No virus found in this incoming message.
                  > Checked by AVG - www.avg.com
                  > Version: 9.0.733 / Virus Database: 271.1.1/2701 - Release Date: 02/21/10 08:34:00
                  >
                  >


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