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

Re: [jslint] Re: Why disallow new as statement?

Expand Messages
  • 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 1 of 7 , Feb 21, 2010
      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 2 of 7 , Feb 21, 2010
        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 3 of 7 , Feb 21, 2010
          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 4 of 7 , Feb 21, 2010
            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 5 of 7 , Feb 22, 2010
              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.