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

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

Expand Messages
  • 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 1 of 6 , Aug 8, 2011
      --- 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 2 of 6 , Aug 16, 2011
        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 3 of 6 , Aug 16, 2011
          --- 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 4 of 6 , Aug 17, 2011
            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.