2013/7/30 Tom Van Cutsem <[email protected]> > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
