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

Re: Early Unused Arguments

Expand Messages
  • sandyhead25
    While I understand the passing of functions as arguments of other functions is a common style in many frameworks it is extremely sloppy. This is an
    Message 1 of 11 , Apr 28, 2012
    • 0 Attachment
      While I understand the passing of functions as arguments of other functions is a common style in many frameworks it is extremely sloppy. This is an unnecessary complexity. You can easily avoid such complicated problems by not writing code this way.

      To your point however, there is a use case that does reflect your concern in a way that is difficult to avoid. This one case is the implied event argument of functions in web browsers other than IE where these functions are directly referenced from that event. In this case the event is passed as an argument so that it can be nullified when so requested or can be tested to determine the event type. In this case the passing of actual arguments can become unnecessarily complicated.

      If the described complication does not match the problems you are encountering then write you code in a less complicated way. There is never a good reason to pass a function as an argument to another function except in reference only to test for type or depth of instantiation, but this is a rare edge case. To pass a function by reference only treat it like any other variable as a name with the parens or arguments. I can say there is never a valid use case because a function can also be defined internally to its parent or referenced via closure, which accomplish the same execution. The difference is that instantiation is separated from declaration.

      The reason why many frameworks use this sloppiness is because they are attempting to provide a means of shorthanded code instead of writing something simple. That is a vanity concern and not an execution concern. While this is an extraordinarily weak argument completely lacking of any rational merit consider its audience.

      Austin

      --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@...> wrote:
      >
      > I realize the topic of unused arguments has been discussed before, but I wanted to raise it again with a suggested alternative behavior.
      >
      > When creating callbacks / event handler functions for an API, you rarely have control over the expected number of arguments, nor their order. While it would be great if all these APIs passed a single object as the first argument, the reality is that they usually pass up to three separate arguments instead.
      >
      > In that case, if you only use the second of those three, the first must still be provided. JSLint naturally warns about these early unused arguments. At the moment the team I work with manually adds comments to avoid warnings, but it quickly becomes unwieldy.
      >
      > So, I'd like to know your thoughts on allowing unused arguments before a used one, but not after. In other words, the following would not cause a warning:
      >
      > MY_API.binder(someElement, 'click', function (a, b) {
      > iAmUsing(b);
      > });
      >
      > The following would raise an "Unused Variable 'c'" warning:
      >
      > MY_API.binder(someElement, 'click', function (a, b, c) {
      > iAmUsing(b);
      > });
      >
      > Thoughts? Could it be a new toleration?
      >
    • Max
      You might want to spend some time on Google, looking up functional programming, what it is, what it is good for. Discover its strengths. There is a whole lot
      Message 2 of 11 , Apr 28, 2012
      • 0 Attachment
        You might want to spend some time on Google, looking up functional
        programming, what it is, what it is good for. Discover its strengths.
        There is a whole lot more to functional programming than 'just a bit of
        sloppiness created by some shoddy frameworks, or some lazy programmers'.
        You might find there is a new wonderful whole world to explore if you
        simply allow yourself. :-)

        On 4/28/2012 4:17 AM, sandyhead25 wrote:
        >
        > While I understand the passing of functions as arguments of other
        > functions is a common style in many frameworks it is extremely sloppy.
        > This is an unnecessary complexity. You can easily avoid such
        > complicated problems by not writing code this way.
        >
        > To your point however, there is a use case that does reflect your
        > concern in a way that is difficult to avoid. This one case is the
        > implied event argument of functions in web browsers other than IE
        > where these functions are directly referenced from that event. In this
        > case the event is passed as an argument so that it can be nullified
        > when so requested or can be tested to determine the event type. In
        > this case the passing of actual arguments can become unnecessarily
        > complicated.
        >
        > If the described complication does not match the problems you are
        > encountering then write you code in a less complicated way. There is
        > never a good reason to pass a function as an argument to another
        > function except in reference only to test for type or depth of
        > instantiation, but this is a rare edge case. To pass a function by
        > reference only treat it like any other variable as a name with the
        > parens or arguments. I can say there is never a valid use case because
        > a function can also be defined internally to its parent or referenced
        > via closure, which accomplish the same execution. The difference is
        > that instantiation is separated from declaration.
        >
        > The reason why many frameworks use this sloppiness is because they are
        > attempting to provide a means of shorthanded code instead of writing
        > something simple. That is a vanity concern and not an execution
        > concern. While this is an extraordinarily weak argument completely
        > lacking of any rational merit consider its audience.
        >
        > Austin
        >
        > --- In jslint_com@yahoogroups.com
        > <mailto:jslint_com%40yahoogroups.com>, "benquarmby" <ben.quarmby@...>
        > wrote:
        > >
        > > I realize the topic of unused arguments has been discussed before,
        > but I wanted to raise it again with a suggested alternative behavior.
        > >
        > > When creating callbacks / event handler functions for an API, you
        > rarely have control over the expected number of arguments, nor their
        > order. While it would be great if all these APIs passed a single
        > object as the first argument, the reality is that they usually pass up
        > to three separate arguments instead.
        > >
        > > In that case, if you only use the second of those three, the first
        > must still be provided. JSLint naturally warns about these early
        > unused arguments. At the moment the team I work with manually adds
        > comments to avoid warnings, but it quickly becomes unwieldy.
        > >
        > > So, I'd like to know your thoughts on allowing unused arguments
        > before a used one, but not after. In other words, the following would
        > not cause a warning:
        > >
        > > MY_API.binder(someElement, 'click', function (a, b) {
        > > iAmUsing(b);
        > > });
        > >
        > > The following would raise an "Unused Variable 'c'" warning:
        > >
        > > MY_API.binder(someElement, 'click', function (a, b, c) {
        > > iAmUsing(b);
        > > });
        > >
        > > Thoughts? Could it be a new toleration?
        > >
        >
      • benquarmby
        Thanks for the reply Austin. I m not 100% sure if you re saying passing functions as arguments is bad per-se (they re first class in JavaScript), or if it s
        Message 3 of 11 , Apr 29, 2012
        • 0 Attachment
          Thanks for the reply Austin. I'm not 100% sure if you're saying passing functions as arguments is bad per-se (they're first class in JavaScript), or if it's just bad to create them inline. If it's the later, you'll get no argument from me. As a general rule, we flatten to named functions wherever possible to reduce excessive nesting.

          So the example I gave before actually would be:

          function someElementClick(a, b) {
          iAmUsing(b);
          }

          MY_API.binder(someElement, 'click', someElementClick);

          Anyway, I don't want to get distracted by where / how functions are created, because that's not actually the question I asked :)


          --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
          >
          > While I understand the passing of functions as arguments of other functions is a common style in many frameworks it is extremely sloppy. This is an unnecessary complexity. You can easily avoid such complicated problems by not writing code this way.
          >
          > To your point however, there is a use case that does reflect your concern in a way that is difficult to avoid. This one case is the implied event argument of functions in web browsers other than IE where these functions are directly referenced from that event. In this case the event is passed as an argument so that it can be nullified when so requested or can be tested to determine the event type. In this case the passing of actual arguments can become unnecessarily complicated.
          >
          > If the described complication does not match the problems you are encountering then write you code in a less complicated way. There is never a good reason to pass a function as an argument to another function except in reference only to test for type or depth of instantiation, but this is a rare edge case. To pass a function by reference only treat it like any other variable as a name with the parens or arguments. I can say there is never a valid use case because a function can also be defined internally to its parent or referenced via closure, which accomplish the same execution. The difference is that instantiation is separated from declaration.
          >
          > The reason why many frameworks use this sloppiness is because they are attempting to provide a means of shorthanded code instead of writing something simple. That is a vanity concern and not an execution concern. While this is an extraordinarily weak argument completely lacking of any rational merit consider its audience.
          >
          > Austin
          >
          > --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@> wrote:
          > >
          > > I realize the topic of unused arguments has been discussed before, but I wanted to raise it again with a suggested alternative behavior.
          > >
          > > When creating callbacks / event handler functions for an API, you rarely have control over the expected number of arguments, nor their order. While it would be great if all these APIs passed a single object as the first argument, the reality is that they usually pass up to three separate arguments instead.
          > >
          > > In that case, if you only use the second of those three, the first must still be provided. JSLint naturally warns about these early unused arguments. At the moment the team I work with manually adds comments to avoid warnings, but it quickly becomes unwieldy.
          > >
          > > So, I'd like to know your thoughts on allowing unused arguments before a used one, but not after. In other words, the following would not cause a warning:
          > >
          > > MY_API.binder(someElement, 'click', function (a, b) {
          > > iAmUsing(b);
          > > });
          > >
          > > The following would raise an "Unused Variable 'c'" warning:
          > >
          > > MY_API.binder(someElement, 'click', function (a, b, c) {
          > > iAmUsing(b);
          > > });
          > >
          > > Thoughts? Could it be a new toleration?
          > >
          >
        • benquarmby
          Just to add another option, what do you think of creating proxy functions to fix an API that uses a lot of arguments in callbacks? Using my previous code as
          Message 4 of 11 , Apr 29, 2012
          • 0 Attachment
            Just to add another option, what do you think of creating proxy functions to "fix" an API that uses a lot of arguments in callbacks?

            Using my previous code as an example:

            function someElementClick(evt) {
            iCanUseThis(evt.context);
            iAmUsing(evt.b);
            }

            MY_API.binder(someElement, 'click', function (a, b, c) {
            someElementClick({
            context: this, // pass "this" so there is no risk of strict violation in a named function
            a: a, // each argument in turn
            b: b,
            c: c
            });
            });

            It adds a reasonable amount of developer overhead, but it's fully JSLint compliant. It also removes the "Strict violation" warning when using "this" inside a named function.

            --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@...> wrote:
            >
            > I realize the topic of unused arguments has been discussed before, but I wanted to raise it again with a suggested alternative behavior.
            >
            > When creating callbacks / event handler functions for an API, you rarely have control over the expected number of arguments, nor their order. While it would be great if all these APIs passed a single object as the first argument, the reality is that they usually pass up to three separate arguments instead.
            >
            > In that case, if you only use the second of those three, the first must still be provided. JSLint naturally warns about these early unused arguments. At the moment the team I work with manually adds comments to avoid warnings, but it quickly becomes unwieldy.
            >
            > So, I'd like to know your thoughts on allowing unused arguments before a used one, but not after. In other words, the following would not cause a warning:
            >
            > MY_API.binder(someElement, 'click', function (a, b) {
            > iAmUsing(b);
            > });
            >
            > The following would raise an "Unused Variable 'c'" warning:
            >
            > MY_API.binder(someElement, 'click', function (a, b, c) {
            > iAmUsing(b);
            > });
            >
            > Thoughts? Could it be a new toleration?
            >
          • sandyhead25
            Please do not make this an ad hominem. Whether or not I am absolutely ignorant of how to write functional code in JavaScript your point adds nothing to the
            Message 5 of 11 , Apr 29, 2012
            • 0 Attachment
              Please do not make this an ad hominem. Whether or not I am absolutely ignorant of how to write functional code in JavaScript your point adds nothing to the technical merits of this conversation.

              --- In jslint_com@yahoogroups.com, Max <max@...> wrote:
              >
              > You might want to spend some time on Google, looking up functional
              > programming, what it is, what it is good for. Discover its strengths.
              > There is a whole lot more to functional programming than 'just a bit of
              > sloppiness created by some shoddy frameworks, or some lazy programmers'.
              > You might find there is a new wonderful whole world to explore if you
              > simply allow yourself. :-)
              >
              > On 4/28/2012 4:17 AM, sandyhead25 wrote:
              > >
              > > While I understand the passing of functions as arguments of other
              > > functions is a common style in many frameworks it is extremely sloppy.
              > > This is an unnecessary complexity. You can easily avoid such
              > > complicated problems by not writing code this way.
              > >
              > > To your point however, there is a use case that does reflect your
              > > concern in a way that is difficult to avoid. This one case is the
              > > implied event argument of functions in web browsers other than IE
              > > where these functions are directly referenced from that event. In this
              > > case the event is passed as an argument so that it can be nullified
              > > when so requested or can be tested to determine the event type. In
              > > this case the passing of actual arguments can become unnecessarily
              > > complicated.
              > >
              > > If the described complication does not match the problems you are
              > > encountering then write you code in a less complicated way. There is
              > > never a good reason to pass a function as an argument to another
              > > function except in reference only to test for type or depth of
              > > instantiation, but this is a rare edge case. To pass a function by
              > > reference only treat it like any other variable as a name with the
              > > parens or arguments. I can say there is never a valid use case because
              > > a function can also be defined internally to its parent or referenced
              > > via closure, which accomplish the same execution. The difference is
              > > that instantiation is separated from declaration.
              > >
              > > The reason why many frameworks use this sloppiness is because they are
              > > attempting to provide a means of shorthanded code instead of writing
              > > something simple. That is a vanity concern and not an execution
              > > concern. While this is an extraordinarily weak argument completely
              > > lacking of any rational merit consider its audience.
              > >
              > > Austin
              > >
              > > --- In jslint_com@yahoogroups.com
              > > <mailto:jslint_com%40yahoogroups.com>, "benquarmby" <ben.quarmby@>
              > > wrote:
              > > >
              > > > I realize the topic of unused arguments has been discussed before,
              > > but I wanted to raise it again with a suggested alternative behavior.
              > > >
              > > > When creating callbacks / event handler functions for an API, you
              > > rarely have control over the expected number of arguments, nor their
              > > order. While it would be great if all these APIs passed a single
              > > object as the first argument, the reality is that they usually pass up
              > > to three separate arguments instead.
              > > >
              > > > In that case, if you only use the second of those three, the first
              > > must still be provided. JSLint naturally warns about these early
              > > unused arguments. At the moment the team I work with manually adds
              > > comments to avoid warnings, but it quickly becomes unwieldy.
              > > >
              > > > So, I'd like to know your thoughts on allowing unused arguments
              > > before a used one, but not after. In other words, the following would
              > > not cause a warning:
              > > >
              > > > MY_API.binder(someElement, 'click', function (a, b) {
              > > > iAmUsing(b);
              > > > });
              > > >
              > > > The following would raise an "Unused Variable 'c'" warning:
              > > >
              > > > MY_API.binder(someElement, 'click', function (a, b, c) {
              > > > iAmUsing(b);
              > > > });
              > > >
              > > > Thoughts? Could it be a new toleration?
              > > >
              > >
              >
            • sandyhead25
              Ben, It is correct that functions are first class objects in JavaScript. That statement goes to the syntax and definition of functions in the language opposed
              Message 6 of 11 , Apr 29, 2012
              • 0 Attachment
                Ben,

                It is correct that functions are first class objects in JavaScript. That statement goes to the syntax and definition of functions in the language opposed to use cases. So, that said it is perfectly valid to push functions into a different function's argument. I am just saying it is unnecessarily complex. There are more direct ways to achieve the same directives. It appears from your code that you are attempting to assign an anonymous function to known DOM node's click event. You can do this as a property of the node.

                someElement.onclick = function (a, b, c) {};

                Austin

                --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@...> wrote:
                >
                > Thanks for the reply Austin. I'm not 100% sure if you're saying passing functions as arguments is bad per-se (they're first class in JavaScript), or if it's just bad to create them inline. If it's the later, you'll get no argument from me. As a general rule, we flatten to named functions wherever possible to reduce excessive nesting.
                >
                > So the example I gave before actually would be:
                >
                > function someElementClick(a, b) {
                > iAmUsing(b);
                > }
                >
                > MY_API.binder(someElement, 'click', someElementClick);
                >
                > Anyway, I don't want to get distracted by where / how functions are created, because that's not actually the question I asked :)
                >
                >
                > --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                > >
                > > While I understand the passing of functions as arguments of other functions is a common style in many frameworks it is extremely sloppy. This is an unnecessary complexity. You can easily avoid such complicated problems by not writing code this way.
                > >
                > > To your point however, there is a use case that does reflect your concern in a way that is difficult to avoid. This one case is the implied event argument of functions in web browsers other than IE where these functions are directly referenced from that event. In this case the event is passed as an argument so that it can be nullified when so requested or can be tested to determine the event type. In this case the passing of actual arguments can become unnecessarily complicated.
                > >
                > > If the described complication does not match the problems you are encountering then write you code in a less complicated way. There is never a good reason to pass a function as an argument to another function except in reference only to test for type or depth of instantiation, but this is a rare edge case. To pass a function by reference only treat it like any other variable as a name with the parens or arguments. I can say there is never a valid use case because a function can also be defined internally to its parent or referenced via closure, which accomplish the same execution. The difference is that instantiation is separated from declaration.
                > >
                > > The reason why many frameworks use this sloppiness is because they are attempting to provide a means of shorthanded code instead of writing something simple. That is a vanity concern and not an execution concern. While this is an extraordinarily weak argument completely lacking of any rational merit consider its audience.
                > >
                > > Austin
                > >
                > > --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@> wrote:
                > > >
                > > > I realize the topic of unused arguments has been discussed before, but I wanted to raise it again with a suggested alternative behavior.
                > > >
                > > > When creating callbacks / event handler functions for an API, you rarely have control over the expected number of arguments, nor their order. While it would be great if all these APIs passed a single object as the first argument, the reality is that they usually pass up to three separate arguments instead.
                > > >
                > > > In that case, if you only use the second of those three, the first must still be provided. JSLint naturally warns about these early unused arguments. At the moment the team I work with manually adds comments to avoid warnings, but it quickly becomes unwieldy.
                > > >
                > > > So, I'd like to know your thoughts on allowing unused arguments before a used one, but not after. In other words, the following would not cause a warning:
                > > >
                > > > MY_API.binder(someElement, 'click', function (a, b) {
                > > > iAmUsing(b);
                > > > });
                > > >
                > > > The following would raise an "Unused Variable 'c'" warning:
                > > >
                > > > MY_API.binder(someElement, 'click', function (a, b, c) {
                > > > iAmUsing(b);
                > > > });
                > > >
                > > > Thoughts? Could it be a new toleration?
                > > >
                > >
                >
              • benquarmby
                Thanks again Austin. I see your point. This argument aside (ba-dum-tish!), my real question is whether JSLint should allow early unused arguments. So
                Message 7 of 11 , Apr 29, 2012
                • 0 Attachment
                  Thanks again Austin. I see your point.

                  This argument aside (ba-dum-tish!), my real question is whether JSLint should allow early unused arguments. So translating my earlier sample:

                  anythingFromAnyApi.onSomeEvent = function (a, b) {
                  iAmUsing(b);
                  };

                  Should JSLint warn that "a" is unused when I can't control the number of arguments in this case?


                  --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                  >
                  > Ben,
                  >
                  > It is correct that functions are first class objects in JavaScript. That statement goes to the syntax and definition of functions in the language opposed to use cases. So, that said it is perfectly valid to push functions into a different function's argument. I am just saying it is unnecessarily complex. There are more direct ways to achieve the same directives. It appears from your code that you are attempting to assign an anonymous function to known DOM node's click event. You can do this as a property of the node.
                  >
                  > someElement.onclick = function (a, b, c) {};
                  >
                  > Austin
                  >
                  > --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@> wrote:
                  > >
                  > > Thanks for the reply Austin. I'm not 100% sure if you're saying passing functions as arguments is bad per-se (they're first class in JavaScript), or if it's just bad to create them inline. If it's the later, you'll get no argument from me. As a general rule, we flatten to named functions wherever possible to reduce excessive nesting.
                  > >
                  > > So the example I gave before actually would be:
                  > >
                  > > function someElementClick(a, b) {
                  > > iAmUsing(b);
                  > > }
                  > >
                  > > MY_API.binder(someElement, 'click', someElementClick);
                  > >
                  > > Anyway, I don't want to get distracted by where / how functions are created, because that's not actually the question I asked :)
                  > >
                  > >
                  > > --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                  > > >
                  > > > While I understand the passing of functions as arguments of other functions is a common style in many frameworks it is extremely sloppy. This is an unnecessary complexity. You can easily avoid such complicated problems by not writing code this way.
                  > > >
                  > > > To your point however, there is a use case that does reflect your concern in a way that is difficult to avoid. This one case is the implied event argument of functions in web browsers other than IE where these functions are directly referenced from that event. In this case the event is passed as an argument so that it can be nullified when so requested or can be tested to determine the event type. In this case the passing of actual arguments can become unnecessarily complicated.
                  > > >
                  > > > If the described complication does not match the problems you are encountering then write you code in a less complicated way. There is never a good reason to pass a function as an argument to another function except in reference only to test for type or depth of instantiation, but this is a rare edge case. To pass a function by reference only treat it like any other variable as a name with the parens or arguments. I can say there is never a valid use case because a function can also be defined internally to its parent or referenced via closure, which accomplish the same execution. The difference is that instantiation is separated from declaration.
                  > > >
                  > > > The reason why many frameworks use this sloppiness is because they are attempting to provide a means of shorthanded code instead of writing something simple. That is a vanity concern and not an execution concern. While this is an extraordinarily weak argument completely lacking of any rational merit consider its audience.
                  > > >
                  > > > Austin
                  > > >
                  > > > --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@> wrote:
                  > > > >
                  > > > > I realize the topic of unused arguments has been discussed before, but I wanted to raise it again with a suggested alternative behavior.
                  > > > >
                  > > > > When creating callbacks / event handler functions for an API, you rarely have control over the expected number of arguments, nor their order. While it would be great if all these APIs passed a single object as the first argument, the reality is that they usually pass up to three separate arguments instead.
                  > > > >
                  > > > > In that case, if you only use the second of those three, the first must still be provided. JSLint naturally warns about these early unused arguments. At the moment the team I work with manually adds comments to avoid warnings, but it quickly becomes unwieldy.
                  > > > >
                  > > > > So, I'd like to know your thoughts on allowing unused arguments before a used one, but not after. In other words, the following would not cause a warning:
                  > > > >
                  > > > > MY_API.binder(someElement, 'click', function (a, b) {
                  > > > > iAmUsing(b);
                  > > > > });
                  > > > >
                  > > > > The following would raise an "Unused Variable 'c'" warning:
                  > > > >
                  > > > > MY_API.binder(someElement, 'click', function (a, b, c) {
                  > > > > iAmUsing(b);
                  > > > > });
                  > > > >
                  > > > > Thoughts? Could it be a new toleration?
                  > > > >
                  > > >
                  > >
                  >
                • Andy Dawson
                  ... Please clarify why: foo(arg, function() { callThis(with, these, arguments); }); Is considered extremely sloppy. AD [Non-text portions of this message have
                  Message 8 of 11 , Apr 30, 2012
                  • 0 Attachment
                    On 28 April 2012 13:17, sandyhead25 <austin.cheney@...> wrote:

                    > **
                    >
                    >
                    > While I understand the passing of functions as arguments of other
                    > functions is a common style in many frameworks it is extremely sloppy.
                    >

                    Please clarify why:

                    foo(arg, function() {
                    callThis(with, these, arguments);
                    });

                    Is considered extremely sloppy.

                    AD


                    [Non-text portions of this message have been removed]
                  • douglascrockford
                    ... Yes it should, because it is often an error. But if you are intentionally writing code that looks like an error, and don t want to be reminded of that
                    Message 9 of 11 , Apr 30, 2012
                    • 0 Attachment
                      --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@...> wrote:

                      > This argument aside (ba-dum-tish!), my real question is whether JSLint should allow early unused arguments. So translating my earlier sample:
                      >
                      > anythingFromAnyApi.onSomeEvent = function (a, b) {
                      > iAmUsing(b);
                      > };
                      >
                      > Should JSLint warn that "a" is unused when I can't control the number of arguments in this case?


                      Yes it should, because it is often an error. But if you are intentionally writing code that looks like an error, and don't want to be reminded of that fact, then use the Tolerate unused parameters option.
                    • benquarmby
                      Thanks for the reply. Of course you re right (an annoying habit). Do you have a suggestion on creating callback / handler functions like this that don t look
                      Message 10 of 11 , Apr 30, 2012
                      • 0 Attachment
                        Thanks for the reply. Of course you're right (an annoying habit).

                        Do you have a suggestion on creating callback / handler functions like this that don't look like errors? (Other than "don't use stupid APIs" that is :)

                        What do you think of this?
                        http://tech.groups.yahoo.com/group/jslint_com/message/2863

                        --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
                        >
                        > --- In jslint_com@yahoogroups.com, "benquarmby" <ben.quarmby@> wrote:
                        >
                        > > This argument aside (ba-dum-tish!), my real question is whether JSLint should allow early unused arguments. So translating my earlier sample:
                        > >
                        > > anythingFromAnyApi.onSomeEvent = function (a, b) {
                        > > iAmUsing(b);
                        > > };
                        > >
                        > > Should JSLint warn that "a" is unused when I can't control the number of arguments in this case?
                        >
                        >
                        > Yes it should, because it is often an error. But if you are intentionally writing code that looks like an error, and don't want to be reminded of that fact, then use the Tolerate unused parameters option.
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.