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

option.stupid

Expand Messages
  • douglascrockford
    JSLint now warns when properties contain the substring Sync . The use of that substring in Nodejs is to identify methods that can cause blockage. Such methods
    Message 1 of 11 , Mar 30, 2012
    • 0 Attachment
      JSLint now warns when properties contain the substring 'Sync'. The use of that substring in Nodejs is to identify methods that can cause blockage. Such methods should never be used.

      These useful warnings can be suppressed by using the new Tolerate stupidity option.
    • John Hawkinson
      Isn t this misnamed? For those of us who write clean Javascript that doesn t depend on Node.js, why would we have to turn on a pejorative option name (tolerate
      Message 2 of 11 , Mar 30, 2012
      • 0 Attachment
        Isn't this misnamed? For those of us who write clean Javascript that
        doesn't depend on Node.js, why would we have to turn on a pejorative
        option name (tolerate stupidity) because of Node.js's questionable
        design choice?

        Is this somehow more stupid than other design choices made by
        frameworks? If the Foo browser adds odd misbehavior on properties that
        contain the substring 'Bar', should we also expect that to be added
        to option.stupid, rather than option.foobar?

        (It's also confusing to me that those who follow the language spec and
        are ignorant of Node.js must *tolerate* the stupidity, whereas those
        who write to the Node.js spec need not do so. This
        seems...semantically reversed)

        --jhawk@...
        John Hawkinson


        > JSLint now warns when properties contain the substring 'Sync'. The
        > use of that substring in Nodejs is to identify methods that can
        > cause blockage. Such methods should never be used.
      • douglascrockford
        ... No, it is very well named.
        Message 3 of 11 , Mar 30, 2012
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:

          > Isn't this misnamed?

          No, it is very well named.
        • Kirk Cerny
          Could the same be said about synchronous AJAX requests? [Non-text portions of this message have been removed]
          Message 4 of 11 , Mar 30, 2012
          • 0 Attachment
            Could the same be said about synchronous AJAX requests?


            [Non-text portions of this message have been removed]
          • douglascrockford
            ... Obviously.
            Message 5 of 11 , Mar 30, 2012
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, Kirk Cerny <kirksemail@...> wrote:
              >
              > Could the same be said about synchronous AJAX requests?

              Obviously.
            • IcedNet Development Team
              Finally an option to rule them all... Peace, Dan
              Message 6 of 11 , Mar 30, 2012
              • 0 Attachment
                Finally an option to rule them all...

                Peace,
                Dan
              • Martin Cooper
                On Fri, Mar 30, 2012 at 11:08 AM, douglascrockford ... There are numerous valid and reasonable use cases for synchronous code in Node.js. To declare the use of
                Message 7 of 11 , Mar 30, 2012
                • 0 Attachment
                  On Fri, Mar 30, 2012 at 11:08 AM, douglascrockford
                  <douglas@...> wrote:
                  > JSLint now warns when properties contain the substring 'Sync'. The use of that substring in Nodejs is to identify methods that can cause blockage. Such methods should never be used.
                  >

                  There are numerous valid and reasonable use cases for synchronous code
                  in Node.js. To declare the use of sync functions to be universally
                  "stupid" suggests a distinct lack of consideration for the breadth of
                  use cases that Node.js is being used to address.

                  Two very simple and very common examples of where synchronous
                  functions are frequently used in Node.js code are command line tools,
                  for which async often makes little sense and only complicates the
                  code, and loading server config at start-up time, for similar reasons.

                  In both of those cases, you *could* use async code. But when there is
                  no good reason for the code to be async, and the sync code would be
                  simpler and easier to write, debug, read and maintain, it is
                  absolutely not "stupid" to make the decision to use the synchronous
                  functions.

                  To tell people that they need to "tolerate stupidity" in order to take
                  the most appropriate approach for their use cases is inappropriate at
                  best.

                  --
                  Martin Cooper


                  > These useful warnings can be suppressed by using the new Tolerate stupidity option.
                  >
                  >
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                • Mark Volkmann
                  I agree with Martin. Why not fix this by changing the name of the option to sync and have it default to false? ... R. Mark Volkmann Object Computing, Inc. On
                  Message 8 of 11 , Mar 30, 2012
                  • 0 Attachment
                    I agree with Martin. Why not fix this by changing the name of the option to
                    "sync" and have it default to false?

                    ---
                    R. Mark Volkmann
                    Object Computing, Inc.

                    On Mar 30, 2012, at 7:55 PM, Martin Cooper <mfncooper@...> wrote:



                    On Fri, Mar 30, 2012 at 11:08 AM, douglascrockford
                    <douglas@...> wrote:
                    > JSLint now warns when properties contain the substring 'Sync'. The use of
                    that substring in Nodejs is to identify methods that can cause blockage.
                    Such methods should never be used.
                    >

                    There are numerous valid and reasonable use cases for synchronous code
                    in Node.js. To declare the use of sync functions to be universally
                    "stupid" suggests a distinct lack of consideration for the breadth of
                    use cases that Node.js is being used to address.

                    Two very simple and very common examples of where synchronous
                    functions are frequently used in Node.js code are command line tools,
                    for which async often makes little sense and only complicates the
                    code, and loading server config at start-up time, for similar reasons.

                    In both of those cases, you *could* use async code. But when there is
                    no good reason for the code to be async, and the sync code would be
                    simpler and easier to write, debug, read and maintain, it is
                    absolutely not "stupid" to make the decision to use the synchronous
                    functions.

                    To tell people that they need to "tolerate stupidity" in order to take
                    the most appropriate approach for their use cases is inappropriate at
                    best.

                    --
                    Martin Cooper

                    > These useful warnings can be suppressed by using the new Tolerate
                    stupidity option.
                    >
                    >
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >



                    [Non-text portions of this message have been removed]
                  • Andy Dawson
                    Alternatively, all the other options could be renamed to follow the same convention so that all uses can consistently need to lookup what options mean instead
                    Message 9 of 11 , Mar 31, 2012
                    • 0 Attachment
                      Alternatively, all the other options could be renamed to follow the same
                      convention so that all uses can consistently need to lookup what options
                      mean instead of having some hint from the option name.

                      as such, lameness, awfulness, javaitis etc. can all become part of the
                      jslint vocabulary

                      AD
                      On Mar 31, 2012 4:08 AM, "Mark Volkmann" <r.mark.volkmann@...> wrote:

                      > I agree with Martin. Why not fix this by changing the name of the option to
                      > "sync" and have it default to false?
                      >
                      > ---
                      > R. Mark Volkmann
                      > Object Computing, Inc.
                      >
                      > On Mar 30, 2012, at 7:55 PM, Martin Cooper <mfncooper@...> wrote:
                      >
                      >
                      >
                      > On Fri, Mar 30, 2012 at 11:08 AM, douglascrockford
                      > <douglas@...> wrote:
                      > > JSLint now warns when properties contain the substring 'Sync'. The use of
                      > that substring in Nodejs is to identify methods that can cause blockage.
                      > Such methods should never be used.
                      > >
                      >
                      > There are numerous valid and reasonable use cases for synchronous code
                      > in Node.js. To declare the use of sync functions to be universally
                      > "stupid" suggests a distinct lack of consideration for the breadth of
                      > use cases that Node.js is being used to address.
                      >
                      > Two very simple and very common examples of where synchronous
                      > functions are frequently used in Node.js code are command line tools,
                      > for which async often makes little sense and only complicates the
                      > code, and loading server config at start-up time, for similar reasons.
                      >
                      > In both of those cases, you *could* use async code. But when there is
                      > no good reason for the code to be async, and the sync code would be
                      > simpler and easier to write, debug, read and maintain, it is
                      > absolutely not "stupid" to make the decision to use the synchronous
                      > functions.
                      >
                      > To tell people that they need to "tolerate stupidity" in order to take
                      > the most appropriate approach for their use cases is inappropriate at
                      > best.
                      >
                      > --
                      > Martin Cooper
                      >
                      > > These useful warnings can be suppressed by using the new Tolerate
                      > stupidity option.
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > ------------------------------------
                      > >
                      > > Yahoo! Groups Links
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Morgaut Alexandre Louis Marc
                      I find this option name fun and maybe It could be a right name in NodeJS context. That said, I also think that there might be some valid use of Sync methods
                      Message 10 of 11 , Apr 2, 2012
                      • 0 Attachment
                        I find this option name fun and maybe It could be a right name in NodeJS context.

                        That said, I also think that there might be some valid use of "Sync" methods in JavaScript. I'm thinking about the Web Workers, and the synchronous SSJS platforms.

                        I know you may not have much consideration for HTML5 (mainly because security should have been addressed in priority) but still...

                        In HTML5, many APIs propose Sync and Async modes:
                        - XMLHttpRequest 1 & 2: http://www.w3.org/TR/XMLHttpRequest/ - http://www.w3.org/TR/XMLHttpRequest2/
                        -> it would not be impacted by this option as is because "Sync" isn't part of property names in the API
                        - File API: http://www.w3.org/TR/FileAPI/
                        - File System API: http://www.w3.org/TR/file-system-api/
                        - File Writer API: http://www.w3.org/TR/file-writer-api/
                        - Indexed Database API: http://www.w3.org/TR/IndexedDB
                        - Web SQL Database (inactive): http://www.w3.org/TR/webdatabase/

                        This didn't make much sense before because it was blocking the User Interface, but now, we have the Web Workers allowing to take advantage of multi-threading (or at least multi processing). It then looks to me that using synchronous APIs in Workers should be perfectly acceptable, even more when we know that the importScript() method available in this context works synchronously.


                        Another point is about other Server-Side JavaScript implementations
                        Most of them have synchronous APIs and take advantage of multi-threading
                        I'm not aware of all the details of all of them, most should not get errors from this option as they don't have "Sync" in their method names. In this case only the option name "stupid" is a bit hard (should our feelings being hurt when we don't choose NodeJS?)
                        To end my purpose, I would also mention Wakanda, which runs JS code on server synchronously by default. It support natively some HTML5 and NodeJS APIs to:
                        - start event loops like contexts when it make sense,
                        - be compatible with some existing libraries,
                        - and of course enhance learning curve.
                        On this platform, not only most of the JavaScript works synchronously, but it would also get the warning while using the synchronous versions of HTML5 APIs.
                        Maybe a warning is ok, because such code could not be reused in any context (main user interface context, or Node.js context), but then, isn't the "stupid" option name a bit too strong?
                      • benquarmby
                        Doug, I don t have a problem with this option, but I would like to suggest a stricter implementation of it s behavior. Instead of broadly catching the
                        Message 11 of 11 , Jun 20, 2012
                        • 0 Attachment
                          Doug,

                          I don't have a problem with this option, but I would like to suggest a stricter implementation of it's behavior.

                          Instead of broadly catching the substring "Sync", limit it to catch functions that *end* with "Sync", since all blocking Node methods appear use this convention.

                          Matching the end will also stop it catching false positives. For example, the completion event handler for an asynchronous synchronize action, i.e. "onGroupSyncComplete".

                          Hope you agree.

                          --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
                          >
                          > JSLint now warns when properties contain the substring 'Sync'. The use of that substring in Nodejs is to identify methods that can cause blockage. Such methods should never be used.
                          >
                          > These useful warnings can be suppressed by using the new Tolerate stupidity option.
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.