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

infix_in warnings

Expand Messages
  • John Hawkinson
    In late Feb, Douglas added this warning: infix_in: Unexpected in . Compare with undefined, or use the hasOwnProperty method instead. , This causes problems
    Message 1 of 6 , Apr 1 6:40 PM
    • 0 Attachment
      In late Feb, Douglas added this warning:

      infix_in: "Unexpected 'in'. Compare with undefined, or use the
      hasOwnProperty method instead.",

      This causes problems for me in Adobe's ExtendScript JavaScript
      implementation[*], where some kind of DOM objects do not return
      'undefined' for undefined properties, but instead throw errors.
      (These are typically objects that are backed by C++ implementations
      in the relevant Adobe application).

      So where I would like to check:

      if (image.effectivePpi && image.effectivePpi[0] < threshold)
      ...

      I cannot. My first reaction is to use

      if ('effectivePpi' in image && image.efffectivePpi < threhsold)

      but that triggers the infix_in warning.
      I am loathe to use

      if (image.hasOwnProperty('effectivePpi') &&
      image.effectivePpi < threshold)

      because I don't know that the effectivePpi property might not be inherited,
      and I do not wish to disregard the inheritance chain.

      It does not appear that /*jslint forin: true */ is sufficient to
      permit this usage.

      Is there a better recommendation?

      I think I have lost track of why the infix form of in is prohibitted;
      I understand why the prefix form should be filtered, but not why the
      infix form is barred.

      Thanks.

      --jhawk@...
      John Hawkinson

      [*] in particular, this is

      "The ExtendScript scripting engine
      Copyright 1998-2010 Adobe Sytems Incoporated
      Version 4.12.2
      Build version 64.447932
      Build date 2010/11/15-23:35:46
      <AdobeIP#0000655>
      ScriptUI version 5.1.37"
    • John Hawkinson
      Any thoughts on the appropriate workaround for infix_in warnings without using .hasOwnProperty() which doesn t follow the inheritance chain? [I m suspecting
      Message 2 of 6 , Apr 5 12:07 AM
      • 0 Attachment
        Any thoughts on the appropriate workaround for infix_in warnings
        without using .hasOwnProperty() which doesn't follow the inheritance
        chain? [I'm suspecting perhaps no one was inclined to think about
        this over the weekend and it got lost in the shuffle?]

        Thanks.

        --jhawk@...
        John Hawkinson

        Date: Fri, 1 Apr 2011 21:40:26 -0400 (EDT)

        In late Feb, Douglas added this warning:

        infix_in: "Unexpected 'in'. Compare with undefined, or use the
        hasOwnProperty method instead.",

        This causes problems for me in Adobe's ExtendScript JavaScript
        implementation[*], where some kind of DOM objects do not return
        'undefined' for undefined properties, but instead throw errors.
        (These are typically objects that are backed by C++ implementations
        in the relevant Adobe application).

        So where I would like to check:

        if (image.effectivePpi && image.effectivePpi[0] < threshold)
        ...

        I cannot. My first reaction is to use

        if ('effectivePpi' in image && image.efffectivePpi < threhsold)

        but that triggers the infix_in warning.
        I am loathe to use

        if (image.hasOwnProperty('effectivePpi') &&
        image.effectivePpi < threshold)

        because I don't know that the effectivePpi property might not be inherited,
        and I do not wish to disregard the inheritance chain.

        It does not appear that /*jslint forin: true */ is sufficient to
        permit this usage.

        Is there a better recommendation?

        I think I have lost track of why the infix form of in is prohibitted;
        I understand why the prefix form should be filtered, but not why the
        infix form is barred.

        Thanks.

        --jhawk@...
        John Hawkinson

        [*] in particular, this is

        "The ExtendScript scripting engine
        Copyright 1998-2010 Adobe Sytems Incoporated
        Version 4.12.2
        Build version 64.447932
        Build date 2010/11/15-23:35:46
        <AdobeIP#0000655>
        ScriptUI version 5.1.37"
      • Douglas Crockford
        ... if (Object.prototype.hasOwnProperty.call(object, key)) { ... } The in operator should have been the hasOwnProperty operator. hasOwnProperty should have
        Message 3 of 6 , Apr 5 4:22 AM
        • 0 Attachment
          ---In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
          >
          > Any thoughts on the appropriate workaround for infix_in warnings
          > without using .hasOwnProperty() which doesn't follow the inheritance
          > chain? [I'm suspecting perhaps no one was inclined to think about
          > this over the weekend and it got lost in the shuffle?]

          if (Object.prototype.hasOwnProperty.call(object, key)) {
          ...
          }

          The in operator should have been the hasOwnProperty operator. hasOwnProperty should have been an operator, not a method, because
          being a method, it is prone to these sorts of problems. But it is
          what it is, so you have to work around that.
        • John Hawkinson
          Again, I *want* to follow the inheritance chain, not to specifically disregard it: function object(o) { function F() {} F.prototype = o; return new F(); }; var
          Message 4 of 6 , Apr 5 5:23 AM
          • 0 Attachment
            Again, I *want* to follow the inheritance chain,
            not to specifically disregard it:

            function object(o) { function F() {} F.prototype = o; return new F(); };
            var o1 = { alpha: 1 };
            var o2 = object(o1);
            ...
            if ('alpha' in o2) { ...


            Sorry if this language was unclear:
            > > Any thoughts on the appropriate workaround for infix_in warnings
            > > without using .hasOwnProperty() which doesn't follow the inheritance
            > > chain?


            > The in operator should have been the hasOwnProperty operator. hasOwnProperty
            > should have been an operator, not a method, because
            > being a method, it is prone to these sorts of problems. But it is
            > what it is, so you have to work around that.

            Am I on a fool's errand? Should I be throwing out the ability of objects
            to inherit and assume that any property inheritance is an error?
            I feel like that's not the right assumption?

            --jhawk@...
            John Hawkinson
          • Luke Page
            It might help if you explain why you *want* to follow the inheritance chain and also whether you mind if your script is included on a page where another script
            Message 5 of 6 , Apr 5 6:04 AM
            • 0 Attachment
              It might help if you explain why you *want* to follow the inheritance chain
              and also whether you mind if your script is included on a page where another
              script (inadvertently) adds something to a base class..


              On 5 April 2011 13:23, John Hawkinson <jhawk@...> wrote:

              >
              >
              > Again, I *want* to follow the inheritance chain,
              > not to specifically disregard it:
              >
              > function object(o) { function F() {} F.prototype = o; return new F(); };
              > var o1 = { alpha: 1 };
              > var o2 = object(o1);
              > ...
              > if ('alpha' in o2) { ...
              >
              > Sorry if this language was unclear:
              >
              > > > Any thoughts on the appropriate workaround for infix_in warnings
              > > > without using .hasOwnProperty() which doesn't follow the inheritance
              > > > chain?
              >
              > > The in operator should have been the hasOwnProperty operator.
              > hasOwnProperty
              > > should have been an operator, not a method, because
              > > being a method, it is prone to these sorts of problems. But it is
              > > what it is, so you have to work around that.
              >
              > Am I on a fool's errand? Should I be throwing out the ability of objects
              > to inherit and assume that any property inheritance is an error?
              > I feel like that's not the right assumption?
              >
              >
              > --jhawk@...
              > John Hawkinson
              >
              >
              >


              [Non-text portions of this message have been removed]
            • John Hawkinson
              Luke Page wrote on Tue, 5 Apr 2011 ... I m looking at host object (DOM object) whose API documentation defines it as inheriting from
              Message 6 of 6 , Apr 5 12:09 PM
              • 0 Attachment
                Luke Page <luke.a.page@...> wrote on Tue, 5 Apr 2011
                at 14:04:02 +0100 in <BANLkTimZ8xhhAQO9v9XDzb6aTnddkQ4T2Q@...>:

                > It might help if you explain why you *want* to follow the
                > inheritance chain

                I'm looking at host object (DOM object) whose API documentation
                defines it as inheriting from another host object. It appears that
                that inheritance is not implemented using JavaScript's inheritance
                mechanism (so .hasOwnProperty() works right now), but I don't see
                why it might not be so implemented in the future, causing code to
                break.

                My goal, again, is to guard a property access so if the object
                is missing the property, I don't get an error, because this host
                object chooses to throw an exception on access to an unknown property,
                as it is entitled to do per 8.6.2 of the 3rd edition spec.

                Remember I wanted to use:

                if (image.effectivePpi && image.effectivePpi[0] < threshold)

                but cannot because the exception is thrown instead of returning null.
                So my preferred choice is an infix 'in':

                if ('effectivePpi' in image && image.effectivePpi < threshold)

                But that upsets JSLint. I guess there are some additional formulations
                that could work for me, like:

                try {
                if (image.effectivePpi[0] < threshold) { ... }
                } catch (e) { /* test for the right exception */ }

                but I really dislike using try/catch that way (is that wrong?).

                Another approach is to explicitly check the type of 'image', since
                there are a bunch of different image types that have an effectivePpi
                property. That's a bad idea since the type of images might change in
                the future and keeping a list of them is guaranteed to get out of
                sync.

                I guess I can just assume that the API is never going to use inheritance
                to manage the .effectivePpi property, and use .hasOwnProperty(); but
                that feels fragile (wrong, even).

                > and also whether you mind if your script is included on a page where
                > another script (inadvertently) adds something to a base class..

                Well, since this is in a closed environment outside a browser, that's
                relatively unlikely. But I would expect that an effectivePpi property
                higher up in the inheritance chain would be consistent with the documented
                behavior.

                But this is why I asked if it was a fool's errand. Striving for
                "correctness."

                --jhawk@...
                John Hawkinson
              Your message has been successfully submitted and would be delivered to recipients shortly.