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

Re: infix_in warnings

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.