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

Re: [jslint] Re: infix_in warnings

Expand Messages
  • 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 1 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

      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

      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

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

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