In most of the use cases of checking if a property is in the prototype
chain (checking a protocol for example) you *do* want to trigger getters
and Proxy traps. When interfacing with a object a developer doesn't need to
be concerned with the implementation behind, if a getter or proxy trap does
a intensive computation or has side effects, it's all bad class/object
design fault. A common example when you want to check a property "return"
rather than it's existence it's virtual properties or class refactoring:
``` js
// old implementation
class Foo {
  constructor() {
    this.foo = 46;
  }
}

// post refactoring
class Foo {
  // implements something different

  // Product of refactoring, undefined it's a placeholder here
  //it can be any value that makes sense in the refactoring
  get foo() { return undefined; }
  set foo(_) {}
}
```
Of course there's some use cases to use property check without triggering
side effects (mostly when working with property descriptors), but the
majority of "property existence check" lays on interface assertion and a
typeof check it's ~generally~ the right choice.

About the `!in` operator, I don't see any problem in it. Of couse the usage
of `in` is most of the time is not recommended, but it has it place. Also
it puts precedence to future operators (like the `hasOwn` proposed here).

Em qui, 19 de jul de 2018 às 10:26, Michael Theriot <
michael.lee.theriot at gmail.com> escreveu:

> > 'string' === typeof document.createElement('input').type
> > // true
>
> It should be noted this is a "loose check"; it does not determine whether
> or not the property exists when its value equals undefined. It also
> triggers getters, whereas `in` reports whether or not the property exists
> without triggering a getter.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
Augusto Moura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180719/138a9f0c/attachment.html>

In most of the use cases of checking if a property is in the prototype
chain (checking a protocol for example) you *do* want to trigger getters
and Proxy traps. When interfacing with a object a developer doesn't need to
be concerned with the implementation behind, if a getter or proxy trap does
a intensive computation or has side effects, it's all bad class/object
design fault. A common example when you want to check a property "return"
rather than it's existence it's virtual properties or class refactoring:
``` js
// old implementation
class Foo {
  constructor() {
    this.foo = 46;
  }
}

// post refactoring
class Foo {
  // implements something different

  // Product of refactoring, undefined it's a placeholder here
  //it can be any value that makes sense in the refactoring
  get foo() { return undefined; }
  set foo(_) {}
}
```
Of course there's some use cases to use property check without triggering
side effects (mostly when working with property descriptors), but the
majority of "property existence check" lays on interface assertion and a
typeof check it's ~generally~ the right choice.

About the `!in` operator, I don't see any problem in it. Of couse the usage
of `in` is most of the time is not recommended, but it has it place. Also
it puts precedence to future operators (like the `hasOwn` proposed here).