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

Collision between global var and function name

Expand Messages
  • IceBox
    JSLint doesn t report any error, because foos is considered global. Any suggestion to avoid that error? Thanks in advance, Alberto ... use strict ; function
    Message 1 of 6 , Sep 8 11:52 PM
    • 0 Attachment
      JSLint doesn't report any error, because "foos" is considered global.

      Any suggestion to avoid that error?

      Thanks in advance,
      Alberto

      --------

      "use strict";

      function foo() {
      var foos;

      foos = 3;
      // ...
      foo = 7; // For a typo I wrote "foo" instead of "foos"

      return foos;
      }

      foo();
      foo(); // getting TypeError
    • IceBox
      ... Typo in the typo... :) I mean foo is considered global. Regards, Alberto
      Message 2 of 6 , Sep 8 11:56 PM
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "IceBox" <albertosantini@...> wrote:
        >
        > JSLint doesn't report any error, because "foos" is considered global.
        >

        Typo in the typo... :)

        I mean "foo" is considered global.

        Regards,
        Alberto
      • Cheney, Edward A SSG RES USAR
        Icebox, You cannot avoid having at least one global variable name. The only way a variable stops being global is from containment by a function, but at some
        Message 3 of 6 , Sep 9 4:03 PM
        • 0 Attachment
          Icebox,

          You cannot avoid having at least one global variable name. The only way a variable stops being global is from containment by a function, but at some point there must be a root function existing at the global level from which the first layer of scope is provided.

          Alluding to an analogy, HTML and XML solve this problem by requiring one single root element per document, and no more, so that access to the global space always limited to a single container.

          Thanks,
          Austin
          http://prettydiff.com/
        • Rob Richardson
          It seems effective to identify if a variable is defined as a function (either var f = function () {... or function f() {...) or not and whine if it switches or
          Message 4 of 6 , Sep 9 7:00 PM
          • 0 Attachment
            It seems effective to identify if a variable is defined as a function
            (either var f = function () {... or function f() {...) or not and whine if
            it switches or a function var get set to null. Or perhaps insure that
            variables inside a function don't match the function name. I realize
            there's no classical "types", but it seems to me that a function which
            within itself sets itself to null is doing bad things. Is it practical to
            do this within jslint?

            The corollary to this is name variables more descriptively such that a typo
            won't make it from one valid var to another.

            Rob
          • Cheney, Edward A SSG RES USAR
            Rob, What is the problem if a function changes its method of definition? I do understand that there is a difference between the method of declaring a function
            Message 5 of 6 , Sep 10 10:55 AM
            • 0 Attachment
              Rob,

              What is the problem if a function changes its method of definition? I do understand that there is a difference between the method of declaring a function with regard to execution versus where the function is defined during procedural interpretation of the code at the interpreter, but what problems can you describe where a function morphs during a given scope? JSLint already complains if a single variable name is defined more than once in a given scope. Are you suggestion it would be helpful for JSLint to always prefer one single format for declaring a function? JSLint does not perform flow control and so it cannot know if there exists some sort of poly morphism in your code, by where a function dynamically changes form.

              What is the problem if a function returns null? I understand that a bug is thrown in a function returns null and is executed as part of a mathematical operation or string concatenation. You can prevent this easily enough by ensuring your functions always return a value or an empty string. JSLint does not perform flow control and so no matter how grave a problem this may be it is best fixed proactively and not from validation.

              There is no problem with a variable matching the name of its containing function, because of a difference in namespaces. The problem that arises is if the variable in question is not declared within the function, such as a closure, because then there exists the possibility of a namespace collision. JSLint warns about declarations that cause collisions, but you are on your own for collisions that are the result of reassignment.

              " I realize there's no classical "types", but it seems to me that a function which within itself sets itself to null is doing bad things."
              Not necessarily. A function does not return a value unless it is told to do so. That is not a bad thing, because not all functions are written to return values. Some functions may act to alter the value of closures and other may act to perform operations or extend prototypes. In these cases the functions are merely containers of code that are available for reuse, but do not return values.

              I promise that I am not trying to be a stickler or a pain. I am just trying to pry some specifics out of you because mentioned several things quickly of which each are open to interpretation.

              "The corollary to this is name variables more descriptively such that a typo won't make it from one valid var to another."
              As I discovered early this spring even well named variables can result in unintended collisions between nested operations provided enough reuse and inadequate scope definitions upon where those names are reused. This is part of the nature of extended complexity that comes with Lambda programming.

              Thanks,
              Austin
            • Rob Richardson
              I think I wasn t adequately clear previously. If a variable whose value is a function changes value to a non-function such as number or string or object, I
              Message 6 of 6 , Sep 10 11:44 AM
              • 0 Attachment
                I think I wasn't adequately clear previously. If a variable whose value is
                a function changes value to a non-function such as number or string or
                object, I see this as a concern. The return value of executing the function
                is correctly irrelevant. My question was given the JSLint codebase, is
                adding such a check practical?

                For example, I'd love if JSLint flagged that all these cases were invalid:

                Case 1:

                var somefunc1 = function () {
                somefunc1 = 1; // or null or {} or etc
                };

                Case 2:

                function somefunc2() {
                somefunc2 = 1; // or null or {} or etc
                };

                Case 3:

                someobj.somefunc3 = function () {
                delete someobj.somefunc3;
                };


                ... and aren't lambdas such wonderfully painful and exhilarating things.
                Not since pointer arithmetic could we get so cleaver in such elegant and
                dangerous ways. ("Is this an array of pointers or a pointer to an array?")
                I so love my career.

                Rob


                -----Original Message-----
                From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
                Behalf Of Cheney, Edward A SSG RES USAR
                Sent: Friday, September 10, 2010 10:56 AM
                To: jslint_com@yahoogroups.com
                Subject: Re: RE: [jslint] Collision between global var and function name

                Rob,

                What is the problem if a function changes its method of definition? I do
                understand that there is a difference between the method of declaring a
                function with regard to execution versus where the function is defined
                during procedural interpretation of the code at the interpreter, but what
                problems can you describe where a function morphs during a given scope?
                JSLint already complains if a single variable name is defined more than once
                in a given scope. Are you suggestion it would be helpful for JSLint to
                always prefer one single format for declaring a function? JSLint does not
                perform flow control and so it cannot know if there exists some sort of poly
                morphism in your code, by where a function dynamically changes form.

                What is the problem if a function returns null? I understand that a bug is
                thrown in a function returns null and is executed as part of a mathematical
                operation or string concatenation. You can prevent this easily enough by
                ensuring your functions always return a value or an empty string. JSLint
                does not perform flow control and so no matter how grave a problem this may
                be it is best fixed proactively and not from validation.

                There is no problem with a variable matching the name of its containing
                function, because of a difference in namespaces. The problem that arises is
                if the variable in question is not declared within the function, such as a
                closure, because then there exists the possibility of a namespace collision.
                JSLint warns about declarations that cause collisions, but you are on your
                own for collisions that are the result of reassignment.

                " I realize there's no classical "types", but it seems to me that a function
                which within itself sets itself to null is doing bad things."
                Not necessarily. A function does not return a value unless it is told to do
                so. That is not a bad thing, because not all functions are written to
                return values. Some functions may act to alter the value of closures and
                other may act to perform operations or extend prototypes. In these cases
                the functions are merely containers of code that are available for reuse,
                but do not return values.

                I promise that I am not trying to be a stickler or a pain. I am just trying
                to pry some specifics out of you because mentioned several things quickly of
                which each are open to interpretation.

                "The corollary to this is name variables more descriptively such that a typo
                won't make it from one valid var to another."
                As I discovered early this spring even well named variables can result in
                unintended collisions between nested operations provided enough reuse and
                inadequate scope definitions upon where those names are reused. This is
                part of the nature of extended complexity that comes with Lambda
                programming.

                Thanks,
                Austin
              Your message has been successfully submitted and would be delivered to recipients shortly.