On Oct 17, 2011, at 3:32 PM, Erik Arvidsson wrote:
> YES! This is the most exciting proposals I've seen in years. I'm so excited!
Thanks...
What started me thinking along this line was noticing how Dart handles [ ] as a
dynamically dispatched method. It isn't the first language to do so and C#
(and C++, for that matter) does something similar statically. Having an
extensible collection access syntax if very handy.
>
> With this we would be able to implement Array and all those pesky DOM
> collections without a hitch [*]. I think it might even allow sub
> classing Array if Array was reimlemented using this mechanism.
Exactly, I was thinking the same things. This is largely why I even bothered
to float what I'm sure is going to be a controversial idea.
>
> [*] What of Object.keys and other reflection like mechanisms? Should
> we have a collectionKeys private name too?
>
I don't see the need. A collection can public expose such methods as normal
properties and how they get implemented are up to the collection
implementation. If you choose to use a normal object as the backing store of a
collection, then the implementation can just use the existing reflection
functions. For example, we could easily add keys to by example class:
import {collectionGetter, collectionSetter} from "@metaCollections";
content = Name.create();
export function StringKeyedMap() {
this@content = Object.create(null); //note content object is a "normal
object" and [ ] on it does regular property access
this@collectionGetter = function(k) {return this@content [k]};
this@collectionSetter = function(k,v) {this@content [k]=v;};
this.size = function() {Object.getOwnPropertyNames(this@content ).length};
//I'm lazy
this.has = function(k) {return {}.hasOwnProperty.call(this@content,k};
this.delete = function(k) {return delete this@content [k]};
this.keys = function() {return Object.keys(this@content)};
}
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
