> In principal, that's how it should work. In practice, since we have to deal
> with objects that don't inherit from Object.prototype I suspect it is best to
> leave the fall back behavior as part of the definition of the operator.
Cool. I don’t care how the details are handled, as long as there is conceptual
clarity. Then it all depends on whether JS programmers can accept the new best
practice of using Object.getProperty() (or something similar). But it makes
tremendous sense: An array becomes more like a collection and an object less
like one.
Someone should really work on a collections library for JavaScript – with the
above change, we have all the ingredients for doing so.
Another idea for computed property name syntax:
let nameObj = name.create();
let obj = {
(nameObj): 0
}
obj.(nameObj)++;
> Also you need another argument in both of your reflection functions:
>
> Object.prototype.operator[]get = function (name) {
> return Object.getProperty(this, name) ;
> }
> Object.prototype.operator[]set = function (name, value) {
> return Object.setProperty(this, name, value);
> }
Correct.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
