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

using 'this' in strict mode

Expand Messages
  • Phil
    The last few versions [the last couple of days] of jslint have been complaining about a Strict violation for every reference to this in my scripts. Is there an
    Message 1 of 6 , Aug 6, 2011
    • 0 Attachment
      The last few versions [the last couple of days] of jslint have been
      complaining about a Strict violation for every reference to this in my
      scripts.

      Is there an online reference guide available for use "use strict"? Is
      there a valid way of using this while in strict mode? I have gone
      through what jslint documentation I have found as well javascript
      documenation, but have not found anything about using this.

      The most common usage in this batch of code, is some function intended
      to work with [in the context of] an array. So I have things like:
      this.length
      this[i]
      isArray(this) /* for validation */
      typeof this
      All of the above complain about strict violations. The containing
      functions are called like:
      arrayFunc.call(srcArr, funcArg)
      at least for now, since I have not added the function to the prototype.



      [Non-text portions of this message have been removed]
    • 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 2 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 3 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 4 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 5 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 6 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.