3 ms·
As a Python guy, where we have __setattr__, __setitem__, etc., I was at first wondering why you would use a proxy for such a thing. Better make it part of the l
by sametmax 8y ago
As a Python guy, where we have __setattr__, __setitem__, etc., I was at first wondering why you would use a proxy for such a thing. Better make it part of the language.
But the more I think about it, the more I can see that it's handy to have an official proxy interface for this, for the case of an external code needing to wrap your object.
Also, I've seen so many reinvented wheels for proxies, and usually bad ones, as it seems an easy problem to solve, but there are plenty of edge cases. Proxies avoid the recursive problem altogether.
Besides, __dundermethods__ tend to make the language hard to optimize.
Still, it's really overkill for simple cases like the ones addressed by Object.defineProperty (or @property for Python), as you create a huge layer of indirection for the entire wrapped object. So if you use such a Proxy, you better have a damn good reason.
- mateuszf 8y agoI think it's a matter of performance. Compiler / interpreter / runtime will only add overhead in lookups for this objects explicitly matched as proxy, but in normal case it can go directly to the cached functions.
- throwaway2016a 8y agoThis is part of the language not just a an interface (though I'm not sure it is an interface, I think it is an object primitive). You wouldn't be able to write this using plain Javascript. Which is why there are no polyfills for client-side code. Incidentally, PHP does it a similar way to Python with so-called "magic methods" but I can see the benefit to doing it this way.