Direct proxies update
allen at wirfs-brock.com
Thu Nov 24 11:22:18 PST 2011
On Nov 24, 2011, at 1:36 AM, Tom Van Cutsem wrote:
> - Definition of a standard "@reflect" module: <http://wiki.ecmascript.org/doku.php?id=harmony:reflect_api>
> One observation I made while working on this module is that it's probably a bad idea to use keywords as trap names (delete, new), since such names cannot be straightforwardly imported/exported from modules. We should probably consider using the names 'deleteProperty' and 'construct' instead.
If we are going to have a @reflection module that is of broader applicability then just writing proxy handlers I'd like us to consider a Mirrors style API. Otherwise I'm a concern will continue to have a proliferation of reflection APIs as we move beyond Proxies into other use cases.
At the core is a root question whether we want to expose a functional or object-oriented API for reflection functionality. These are two different styles each of which is probably favored by a different subset of our user community. I suspect that everyone knows which sub-community I align with. The main argument for the OO style is that it allows creation of client code that can be oblivious to the underlying implementation of the API. The allows for more flexible client code that has greater potential for reuse.
I haven't pushed for adopting mirrors into ES.next because I thought we already had too much on the table. However, if we are going to create new reflection APIs then I think we should carefully consider the pros and cons of the mirrors style.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss