On Wed, Oct 19, 2011 at 8:30 AM, Axel Rauschmayer <[email protected]> wrote:
> >> Then we can continue to use . and [] to access properties and use @[] to > access data structure elements. I wouldn’t like the asymmetry introduced by > using [] for the latter task. > > > > this is plausible and certainly a way to avoid outrage about defining [ > ]. I'll have to stew on it a bit to see if I like it better or less. > > An equally clean alternative (apologies if this is what you meant all > along): > - Discourage [] for accessing properties via computed names, in favor of a > reflective function (if possible as part of a module and not an Object.* > method), e.g. getPropertyByName(obj, name) and setPropertyByName(obj, name, > value). > - Let [] default to using these methods on objects and arrays. > - Use [] freely for collections and dicts. One can use either special name > objects, special names or new names for operators, e.g. operator[] and > operator[]= > > PROBLEM: the easy way of using name objects goes away: this[nameObject] > > Thus, there really are two alternatives: > 1. Changing [] in the above manner plus object@nameObject for accessing > properties (as you suggested). > 2. [] stays as it is and @[] (perhaps there is something slicker, e.g. .[]) > is introduced for collections and dicts. > > Instead of creating a lot of complicated rules for 'object', how about creating a new type 'collection'? Code which depended upon a closed, fixed set of types might break, but I guess that risk is small compared to the potential confusion of redefining []. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
