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 https://github.com/allenwb/jsmirrors is a first cut of a mirrors API that I threw together earlier this year for JavaScript. I don't hold it up as a finished product but it could be a starting point for this sort of design. 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. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
