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

Re: infix_in warnings

Expand Messages
  • Douglas Crockford
    ... if (Object.prototype.hasOwnProperty.call(object, key)) { ... } The in operator should have been the hasOwnProperty operator. hasOwnProperty should have
    Message 1 of 6 , Apr 5, 2011
    • 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 2 of 6 , Apr 5, 2011
      • 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 3 of 6 , Apr 5, 2011
        • 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 4 of 6 , Apr 5, 2011
          • 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.