Re:Use cases for ES6 proxies
by cjhveal on Wednesday July 20, 2016 @12:03AM
(#12126817)
This is a great article. Proxies really have gotten lost in the hype around ES6. Surely it's in part because JS developers have obvious pain points with async control flow and clumsy syntax, so things like generators and generous helpings of syntactic sugar are the most visible changes. However, I'm inclined to think that the level of abstraction and the complex API make it difficult for many developers to recognize their use cases or even play around with them.
[ Parent
| on HN ]
Its because proxies are too hard to compile to ES5. Every function call, array access, property access etc is potentially going to end up calling a proxy, and as such will have to be compiled to impossible-to-read code.
Also, all of the examples given there can be implemented more elegantly using decorators.
The more useful cases are dynamically generated method names (e.g. for ORMs) and array index access (e.g. MobX) for non-array datastructures, both of which could've been handled with a less invasive language feature...
Re:Use cases for ES6 proxies
by qwertyuiop924 on Wednesday July 20, 2016 @07:35AM
(#12128215)
On the contrary, I can think of tons of uses for proxies, from Ruby-style MethodMissing, to object.observe functionality.
For a dynamic set of properties, an observable dictionary is better. For a fixed and known set of properties, its possible to enumerate them with "@observable" decorators beforehand (e.g. see MobX)
Method missing is an alternative to proxies, not a feature.
IMO, a lot of use cases for proxies are mistakes and/or better handled without them.
Re:Use cases for ES6 proxies
by qwertyuiop924 on Thursday July 21, 2016 @05:11PM
(#12140107)
What? No. MethodMissing is far more limited than proxies. Proxies are effectively a far more complex version of Python's properties.
@observable isn't part of the language, and indeed may use proxies under the surface.
Yes, method missing is a far more limited alternative to proxies. But its not a use case for proxies, they just have intersecting sets of use cases. It doesn't make sense to "just" implement method_missing, you would do that so that you can implement other things on top of method_missing.
@observable does not need proxies. Only implementing operator[] does. Which also could've been done with a far more limited feature, namely adding a symbol for the [] method.
Proxies are just silly.
What do you think about immutable data structures as a use case? (e.g. https://facebook.github.io/immutable-js/)
Re:Use cases for ES6 proxies
by wrong_variable on Wednesday July 20, 2016 @11:09AM
(#12129601)
I didn't read the username but then saw 'MobX' and went 'wait a minute'