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

Re: [jslint] using 'this' in strict mode

Expand Messages
  • Frederik Dohr
    ... There are a plenty of resources on ES5 strict mode, e.g. http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/
    Message 1 of 6 , Aug 7, 2011
    • 0 Attachment
      > Is there an online reference guide available for use "use strict"?

      There are a plenty of resources on ES5 strict mode, e.g.
      http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/
      http://javascriptweblog.wordpress.com/2011/05/03/javascript-strict-mode/
      https://developer.mozilla.org/en/JavaScript/Strict_mode

      > The containing functions are called like:
      > arrayFunc.call(srcArr, funcArg)

      This doesn't seem very sensible to me - why not pass the respective
      object (array) as an explicit argument:
      doStuff(array, arg)

      > at least for now, since I have not added the function to the prototype

      FWIW, extending built-in prototypes is generally considered bad
      practice. (I'm sure others here can provide pointers explaining why.)


      -- F.
    • Phil
      ... http://javascriptweblog.wordpress.com/2011/05/03/javascript-strict-mode/ ... I have gone through those links (and more), but do not see anything about
      Message 2 of 6 , Aug 8, 2011
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
        >
        > > Is there an online reference guide available for use "use strict"?
        >
        > There are a plenty of resources on ES5 strict mode, e.g.
        > http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/
        >
        http://javascriptweblog.wordpress.com/2011/05/03/javascript-strict-mode/
        > https://developer.mozilla.org/en/JavaScript/Strict_mode
        >
        I have gone through those links (and more), but do not see anything
        about limitations on using "this" in strict mode. The only thing I
        found related to "this" was about not being boxed into an object.

        > > The containing functions are called like:
        > > arrayFunc.call(srcArr, funcArg)
        >
        > This doesn't seem very sensible to me - why not pass the respective
        > object (array) as an explicit argument:
        > doStuff(array, arg)
        Preparation for using the mixin pattern, and adding to prototype. I
        actually have both versions of the function: function doStuff(array,
        arg) { return arrayFunc.call(array, arg); }
        IMO chaining like:
        obj.fa1(arga1, arga2).fb1(argb1, argb2).fc1(argc1, argc2)
        looks cleaner, and is easier to understand than the equivalent
        fc2(fb2(fa2(obj, arga1, arga2), argb1, argb2), argc1, argc2)
        With the 'mixed' function versions available, that becomes
        fa2(obj, arga1, arga2).fb1(argb1, argb2).fc1(argc1, argc2)
        >
        > > at least for now, since I have not added the function to the
        prototype
        >
        > FWIW, extending built-in prototypes is generally considered bad
        > practice. (I'm sure others here can provide pointers explaining why.)
        Extending the prototype always has the potential of conflicting with
        other code that makes assumptions about the 'hosting' element. Similar
        to using global variables, but that seems to be the method used by the
        [ajax] library code that I have looked at. I am still exploring what is
        possible. If other techniques work [cleanly, efficiently] for providing
        additional or cross browser cleanup [standardization] functionality, I
        have not encountered it yet.

        Still looking for JSLint's *reason* for flagging the use of "this" as a
        strict mode violation. And the *proper* way of providing that type of
        functionality.
        >
        >
        > -- F.
        >
        -- Phil
      • paulcrowder1979
        Crockford explains his reasoning in this post . Personally I find this rule unacceptable, and
        Message 3 of 6 , Aug 16, 2011
        • 0 Attachment
          Crockford explains his reasoning in this post
          <http://tech.groups.yahoo.com/group/jslint_com/message/1553> .
          Personally I find this rule unacceptable, and there should at least be
          an option to override it if it must be default JSLint behavior. Good
          code can be written using "this" inside a function. I've yet to hear a
          convincing argument as to why this is bad code, as its the best way to
          access the DOM element that triggered the event without causing a memory
          leak via a circular reference:
          (function () { function myChangeHandler() { var v =
          this.value; }
          document.getElementById("myTextbox").addEventListener("change",
          myChangeHandler);}());
          Many JavaScript libraries such as ExtJS rely on using "this" to pass
          parameters to an event handler. JavaScript 1.8.5 also introduced the
          bind() method
          <https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Fu\
          nction/bind> on the Function object's prototype which allows a copy of
          a function to be created that always uses the specified object as its
          scope. The use of "this" in functions isn't going away; if anything, it
          is going to become more prevalent as new features are added to the
          language. It's unreasonable rules like this that are starting to turn
          me off to JSLint.


          [Non-text portions of this message have been removed]
        • Phil
          ... Ah! Thanks. Following through the rest of that thread, the solution is simple [for my case anyway]. Just change the function definitions from function
          Message 4 of 6 , Aug 16, 2011
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, "paulcrowder1979" <paul@...> wrote:
            >
            > Crockford explains his reasoning in this post
            > <http://tech.groups.yahoo.com/group/jslint_com/message/1553> .

            Ah! Thanks.

            Following through the rest of that thread, the solution is simple [for my case anyway]. Just change the function definitions from
            function name() {
            stuff with this
            }
            to
            name = function () {
            stuff with this
            };

            plus adding the function names to the list of vars at the top of module (the 'outer' function). No more complaints, no change in functionality.

            [ .. snip .. snip .. ]
          • Marcos Zanona
            Actually if you work with even listeners it is quite easy to understand why `this` isn t accepted in all cases: ### In the following case `this` is accepted
            Message 5 of 6 , Aug 17, 2011
            • 0 Attachment
              Actually if you work with even listeners it is quite easy to understand why `this` isn't accepted in all cases:

              ###
              In the following case `this` is accepted because its it possible to understand that `this` is inherited to the button scope.
              ----
              button.addEventListener('click', function (event) {
              this.innerText = 'Clicked';
              }, false);
              ----

              ###
              In the following example, `this` violates the rule because it isn't really possible to know which scope `this` is referring to:
              ----
              function onClick(event) {
              this.innerText = 'Clicked'; //what's `this` scope here? window?
              event.target.innerText = 'Clicked'; //this becomes a good alternative;
              }

              button.addEventListener('click', onClick, false);
              ----

              This way I could understand really what this rule is all about, makes sense if you think. And as Crockford says, it feels more professional I believe, but that's just my opinion :)
            Your message has been successfully submitted and would be delivered to recipients shortly.