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

Re: [jslint] Double negative

Expand Messages
  • Erik Eckhardt
    I ve always wondered why the values were backward and thought it a little confusing. I don t use them (yet) so it hasn t been an issue for me, but figured I
    Message 1 of 8 , Jun 7 12:47 PM
    • 0 Attachment
      I've always wondered why the values were backward and thought it a little
      confusing. I don't use them (yet) so it hasn't been an issue for me, but
      figured I would weigh in. Plus I have an idea:

      Instead of considering each option a value unto itself, could you require
      specifying the value, such as:

      onevar:true
      onevar:false

      This would let you maintain backwards compatibility but also let you flip
      the meaning of the options you want. If each one had a proper scope, then at
      the top of the entire script the "default" could be set. You could even
      allow `onevar:revert` to go back to the previously-set value--whatever it
      is--allowing the options to be set for portions of the script without having
      to create a new function scope.

      Erik

      On Tue, Jun 7, 2011 at 12:30 PM, Douglas Crockford <douglas@...>wrote:

      >
      >
      > I want to change the polarity of the left most options: white, onevar,
      > undef, nomen, regexp, plusplus, bitwise, newcap, strict. I think it is
      > confusing to have Disallow options. I think Allow/Tolerate options make more
      > sense.
      >
      > But I don't know how to make this change without creating a tremor in the
      > force. The quickest way would be to suddenly reverse polarity. For users on
      > the browser version, the [Clear Options] and [Good Parts] buttons become a
      > single button, so that doesn't seem a big problem.
      >
      > The troublesome case is the people who have /*jslint*/ directives using
      > those options. Those directives would have to be edited, which is really
      > unfortunate.
      >
      > So I want to make this change, but I'm not sure it is worth the cost.
      > Comments?
      >
      >
      >


      [Non-text portions of this message have been removed]
    • John Hawkinson
      I have been bothered by the inconsistency as well, and would favor adopting a syntax change that is unambiguous, while permitting the old syntax to remain for
      Message 2 of 8 , Jun 7 12:59 PM
      • 0 Attachment
        I have been bothered by the inconsistency as well, and would
        favor adopting a syntax change that is unambiguous, while permitting
        the old syntax to remain for compatibility.

        I don't like Erik's proposal though, I have scripts with onevar: true,
        and would like them not to break.

        Perhaps permitting values like 'allow' and 'deny', e.g.

        /*jslint onevar: allow*/
        instead of
        /*jslint onevar: true*/

        and

        /*jslint bitwise: allow*/
        instead of
        /*jslint bitwise: false*/

        --jhawk@...
        John Hawkinson
      • Erik Eckhardt
        My proposal was possibly tainted by ignorance of exactly how the options are used, but anyway the germ of the idea is to come up with a new syntax to
        Message 3 of 8 , Jun 7 1:28 PM
        • 0 Attachment
          My proposal was possibly tainted by ignorance of exactly how the options are
          used, but anyway the germ of the idea is to come up with a new syntax to
          unambiguously cover the flipped meaning of the terms. That part of the idea
          still seems to be valid.

          John, I think you meant `deny` in your second example below. I tweaked it
          for you.

          Erik

          On Tue, Jun 7, 2011 at 12:59 PM, John Hawkinson <jhawk@...> wrote:

          >
          >
          > I have been bothered by the inconsistency as well, and would
          > favor adopting a syntax change that is unambiguous, while permitting
          > the old syntax to remain for compatibility.
          >
          > I don't like Erik's proposal though, I have scripts with onevar: true,
          > and would like them not to break.
          >
          > Perhaps permitting values like 'allow' and 'deny', e.g.
          >
          > /*jslint onevar: allow*/
          > instead of
          > /*jslint onevar: true*/
          >
          > and
          >
          > /*jslint bitwise: deny*/
          > instead of
          > /*jslint bitwise: false*/
          >
          > --jhawk@...
          > John Hawkinson
          >
          >


          [Non-text portions of this message have been removed]
        • John Hawkinson
          Erik Eckhardt wrote on Tue, 7 Jun 2011 ... No, it was as I stated it. Setting bitwise to true prohibits the use of bitwise operators,
          Message 4 of 8 , Jun 7 1:37 PM
          • 0 Attachment
            Erik Eckhardt <erik@...> wrote on Tue, 7 Jun 2011
            at 13:28:27 -0700 in <BANLkTimLBUWbqdu15RT9U4KHBM+bsTv+8w@...>:

            > John, I think you meant `deny` in your second example below. I tweaked it
            > for you.

            No, it was as I stated it. Setting bitwise to true prohibits the
            use of bitwise operators, which would imply denial. So bitwise: allow
            must set bitwise to false, which permits them.

            This is the very inconsistency at-issue here. "allow" means true
            for onevar, but false for bitwise.

            --jhawk@...
            John Hawkinson
          • Erik Eckhardt
            I will be quiet now. :) ... [Non-text portions of this message have been removed]
            Message 5 of 8 , Jun 7 3:47 PM
            • 0 Attachment
              I will be quiet now. :)

              On Tue, Jun 7, 2011 at 1:37 PM, John Hawkinson <jhawk@...> wrote:

              >
              >
              > Erik Eckhardt <erik@...> wrote on Tue, 7 Jun 2011
              > at 13:28:27 -0700 in <BANLkTimLBUWbqdu15RT9U4KHBM+bsTv+8w@...>:
              >
              >
              > > John, I think you meant `deny` in your second example below. I tweaked it
              > > for you.
              >
              > No, it was as I stated it. Setting bitwise to true prohibits the
              > use of bitwise operators, which would imply denial. So bitwise: allow
              > must set bitwise to false, which permits them.
              >
              > This is the very inconsistency at-issue here. "allow" means true
              > for onevar, but false for bitwise.
              >
              >
              > --jhawk@...
              > John Hawkinson
              >
              >
              >


              [Non-text portions of this message have been removed]
            • spence.randall@ymail.com
              I use the /*jslint*/ directives for some of these options, so I would have to edit these, but I think a change for the better is worth the effort. No pain, no
              Message 6 of 8 , Jun 7 8:05 PM
              • 0 Attachment
                I use the /*jslint*/ directives for some of these options, so I would have to edit these, but I think a change for the better is worth the effort. No pain, no gain, right?

                -Randall

                --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                >
                > So I want to make this change, but I'm not sure it is worth the cost. Comments?
                >
              • Merlin
                I would support a change, but I think it would be desirable to continue to support the current /*jslint*/ directive for a while, with the current polarity
                Message 7 of 8 , Jun 8 5:26 AM
                • 0 Attachment
                  I would support a change, but I think it would be desirable to continue to support the current /*jslint*/ directive for a while, with the current polarity convention.

                  A new /*options*/ directive in JSLint could observe the new switched polarity convention.

                  Editing the old form in scripts into the new would be fairly simple - mainly a matter of deleting items that are in the "good parts". A program to do that would be trivial.

                  It does, of course, involve changes in the web interface, and, in my case, in my Widget Tester Widget, but I don't see that as a problem given reasonable notice of the new interface wording and the Edition in which JSLint itself would change.

                  --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                  >
                  > I want to change the polarity of the left most options: white, onevar, undef, nomen, regexp, plusplus, bitwise, newcap, strict. I think it is confusing to have Disallow options. I think Allow/Tolerate options make more sense.
                  >
                  > But I don't know how to make this change without creating a tremor in the force. The quickest way would be to suddenly reverse polarity. For users on the browser version, the [Clear Options] and [Good Parts] buttons become a single button, so that doesn't seem a big problem.
                  >
                  > The troublesome case is the people who have /*jslint*/ directives using those options. Those directives would have to be edited, which is really unfortunate.
                  >
                  > So I want to make this change, but I'm not sure it is worth the cost. Comments?
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.