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

Re: Why disallow new as statement?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.