May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem tomvc.be at gmail.com
Sun Jun 19 08:22:42 PDT 2011


2011/6/18 David Bruant <david.bruant at labri.fr>

> Le 18/06/2011 00:47, David Flanagan a écrit :
> > Given that the fixed properties proposal is adding a return value to
> > defineProperty, perhaps returning false would be a suitable way to
> > reject a property definition.
>

Yes, I think such an API could work.


> I would see this as a weird semantic collision. If I return undefined,
> should it be considered as a falsy value or an inappropriate property
> descriptor? If I return {} or [], is it a truthy value or an invalid
> property descriptor?


- |undefined| is falsy, so interpret as a reject.
- {} is a valid, empty property descriptor.
- For [], or any other non-falsy, non-object value either one could 1)
ignore such values, 2) interpret them as 'rejects', or 3) interpret them as
illegal property descriptors, which should trigger a TypeError. I would opt
for 3), as if the internal Proxy code does:

let res = handler.defineProperty(...);
if (res) {
  desc = ToPropertyDescriptor(res); // throws TypeError if res is a
non-Object value
  ...
} else {
  reject();
}

But before continuing this discussion, I'd like to take measure of how
important it actually is for the Proxy API to be able to faithfully emulate
ES5.1 reject behavior in non-strict mode. Say some non-strict ES5.1 code is
executing Object.defineProperty(...) on a proxy and it throws a TypeError
rather than failing silently. Is that a big deal or just a minor annoyance?
As Mark recently mentioned, to ES5.1 code, proxies are like host objects,
which may already trigger such behavior anyway. OTOH, it might preclude the
use of Proxies to transparently wrap existing ES5.1 objects.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110619/a2b60334/attachment.html>


More information about the es-discuss mailing list