2013/7/30 Tom Van Cutsem <tomvc.be at gmail.com>

> tl;dr:
>
> I would argue that Array.isArray should return true for proxies-for-arrays.
> The other built-ins are less crucial and could stay the way they are.
>
What about WeakMaps? Maps? Sets?
How is the line drawn between "crucial" and "less crucial"? How is going to
be decided whether new exotic object types are crucial?
I feel the line is very context-specific. I can easily agree that arrays
are more used than other exotic objects *for now* (WeakMap/Map/Set may
change that, we'll see), but a Date enhancing library will want to work
with proxies (proxies it does not have necessarily created), and it will
become crucial for proxies-on-dates to work there.
Importance is relative to context and doing a "common denominator" analysis
to assess importance can be detrimental for specific use cases.


"I agree that it is not safe to generalize: a proxy for an X is not in
general substitutable for X."
=> How much unsafe? What are the risks? (implementation concerns don't
apply. Let's solve this with tests. Implementors can also add assertions,
very much as they do today anyway [1])
A built-in algorithm will misbehave? I think that all of them don't have
side-effects beyond the objects being acted upon. Worst case, it will
throw, which is a regular risk anyway for a lot of built-in algorithms
anyway.
This risk already exists if an Array.prototype method is applied to an
object with funky getter/setters (for "length" or numerical properties).

David

[1] http://dbaron.org/log/20130729-debug-builds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130730/0acac422/attachment-0001.html>

2013/7/30 Tom Van Cutsem <tomvc.be at gmail.com>

> tl;dr:
>
> I would argue that Array.isArray should return true for proxies-for-arrays.
> The other built-ins are less crucial and could stay the way they are.
>

What about WeakMaps? Maps? Sets?
How is the line drawn between "crucial" and "less crucial"? How is going to
be decided whether new exotic object types are crucial?
I feel the line is very context-specific. I can easily agree that arrays
are more used than other exotic objects *for now* (WeakMap/Map/Set may
change that, we'll see), but a Date enhancing library will want to work
with proxies (proxies it does not have necessarily created), and it will
become crucial for proxies-on-dates to work there.
Importance is relative to context and doing a "common denominator" analysis
to assess importance can be detrimental for specific use cases.


"I agree that it is not safe to generalize: a proxy for an X is not in
general substitutable for X."
=> How much unsafe? What are the risks? (implementation concerns don't apply. Let's solve this with tests. Implementors can also add assertions, very much as they do today anyway [1])
A built-in algorithm will misbehave? I think that all of them don't have
side-effects beyond the objects being acted upon. Worst case, it will
throw, which is a regular risk anyway for a lot of built-in algorithms
anyway.
This risk already exists if an Array.prototype method is applied to an
object with funky getter/setters (for "length" or numerical properties).

[1]: http://dbaron.org/log/20130729