Standard @iter module unfriendly to collection builders
The Iterators proposal includes the definition (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of functions that are intended to support various common iteration patterns. For example, for ((k of keys(x)) { ...} for (v of values(x)) { ...} for ([k,v] of items(x)) {...} for (k of allKeys(x)) { ...} for (k of allValues(x)) { ...} for (i of allItems(x)) { ...} The use of these functions seems to be pretty much an essential part of the intended use of the for-of statement. Most object-oriented framework designer would immediately see a flaw in this design. keys, values, items, etc. are all functions that incorporate into them a specific collection element storage model. This makes it impossible to use them with new collections that uses a different storage model. For example, they would not work over a binary tree based collection. In providing better forms of iteration for the language, it is important that we do not box it into a specific collection implementation. We want ES to be a first tier language that fully supports the creation of rich collection abstractions with a broad range of functional and performance trade-off. Operations, such as these iteration functions need to be dynamically dispatched, based upon the type of collection they are applied to. A OO designer would simply avoid this problem by replacing these functions with methods (or getter properties): for ((k of x.keys) { ...} for (v of x.values) { ...} for ([k,v] of x.items) {...} for (k of x.allKeys) { ...} for (k of x.allValues) { ...} for (i of x.allItems) { ...} However, some may find this formulation less attractive or have other reasons to prefer a functional formulation. If we perfer to adopt the functional formulation, then it should be done in a manner that does the necessary dynamic dispatch. For example: export function keys(obj) { return { [iterator]: function(() {return obj.keys} } } Note that if there was a concern about property name conflicts with "keys", "values", etc. and the data storage keys of property access based collections, then built-in private names should be specified instead of these names for the corresponding method/getter property names. There might also be a concern that this forces all collection implementors to code these iterator methods. That issue could be avoided by defining the built-in functions to conditionally check for the corresponding methods of the collection object and to fall back to a default implementation. However, it isn't obvious that the property based backing store is the best long term default for collections. A different issue: it isn't clear why the distinction between own and inherited properties are built into these iterator functions. This is not a distinction that would apply to many new collection abstractions. Even if it is a useful distinction,making "own property" iteration be the default seems wrong. The inheritance structure of an object should be an object implementation issue, not an object client usage issue. For example, whether a call: let collection = (new Collection("a",1,"b",2,"c",3)).update("a",4"); results in an object that looks like {a:4,b:2,c:3} or an object that looks like {a:1,b:2,c:3}<|{a:4} should not be relevant to most clients. We are putting lots of energy into trying to support better object-oriented abstraction capabilities, up to and including class literals. We should also be making sure that the other features we add to ES.next also support good object-oriented design principles. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote: > The Iterators proposal includes the definition > (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of > functions that are intended to support various common iteration patterns. > > For example, > > for ((k of keys(x)) { ...} > for (v of values(x)) { ...} > for ([k,v] of items(x)) {...} > for (k of allKeys(x)) { ...} > for (k of allValues(x)) { ...} > for (i of allItems(x)) { ...} > > The use of these functions seems to be pretty much an essential part of the > intended use of the for-of statement. The prior question is what, if anything, for (x of y) ... // and [x for x of y], etc. means. Should it throw if there's no @iterator private-named property in y *and* y is not a Proxy with an iterate trap? That is our current thinking. It may not be reflected well in the wiki. The alternative is to iterate over property values of an object denoted y that has no unstratified @iterator or stratified handler iterate trap. But that is hostile to collections and your [] proposal. OTOH I see no problem for collection writers if we make for-of throw on untrapped objects. Collection authors would bind @iterator, @elementGet, and @elementSet. Life would be grand. Right? /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
Another thing to consider is whether these functions belong in an iter module or in a reflect module? I'm leaning towards the letter. On Nov 12, 2011 12:05 PM, "Brendan Eich" wrote: > On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote: > > The Iterators proposal includes the definition ( > http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) > of functions that are intended to support various common iteration patterns. > > For example, > > for ((k of keys(x)) { ...} > for (v of values(x)) { ...} > for ([k,v] of items(x)) {...} > for (k of allKeys(x)) { ...} > for (k of allValues(x)) { ...} > for (i of allItems(x)) { ...} > > The use of these functions seems to be pretty much an essential part of > the intended use of the for-of statement. > > > The prior question is what, if anything, > > for (x of y) ... // and [x for x of y], etc. > > means. > > Should it throw if there's no @iterator private-named property in y *and* > y is not a Proxy with an iterate trap? That is our current thinking. It may > not be reflected well in the wiki. > > The alternative is to iterate over property values of an object denoted y > that has no unstratified @iterator or stratified handler iterate trap. But > that is hostile to collections and your [] proposal. > > OTOH I see no problem for collection writers if we make for-of throw on > untrapped objects. Collection authors would bind @iterator, @elementGet, > and @elementSet. Life would be grand. Right? > > /be > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 13, 2011, at 10:17 AM, Erik Arvidsson wrote: > Another thing to consider is whether these functions belong in an iter module > or in a reflect module? I'm leaning towards the letter. > Does it matter, apart from the name? I'd rather have more and more precisely defined modules than one reflect dumping ground. JS has built-in reflection, from day 1, arguably overloaded with base-level operations but part of the package deal. We won't be factoring all such unstratified reflection out. The "@iter" name is short and Python-inspired, it should match for-of loops, comprehensions, and generators. It could grow too large, but it wouldn't be larger than "@reflect". If we end up with a standard prelude, some of these helpers could be imported by it. /be > On Nov 12, 2011 12:05 PM, "Brendan Eich" wrote: > On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote: > >> The Iterators proposal includes the definition >> (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of >> functions that are intended to support various common iteration patterns. >> >> For example, >> >> for ((k of keys(x)) { ...} >> for (v of values(x)) { ...} >> for ([k,v] of items(x)) {...} >> for (k of allKeys(x)) { ...} >> for (k of allValues(x)) { ...} >> for (i of allItems(x)) { ...} >> >> The use of these functions seems to be pretty much an essential part of the >> intended use of the for-of statement. > > The prior question is what, if anything, > > for (x of y) ... // and [x for x of y], etc. > > means. > > Should it throw if there's no @iterator private-named property in y *and* y > is not a Proxy with an iterate trap? That is our current thinking. It may not > be reflected well in the wiki. > > The alternative is to iterate over property values of an object denoted y > that has no unstratified @iterator or stratified handler iterate trap. But > that is hostile to collections and your [] proposal. > > OTOH I see no problem for collection writers if we make for-of throw on > untrapped objects. Collection authors would bind @iterator, @elementGet, and > @elementSet. Life would be grand. Right? > > /be > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 12, 2011, at 12:05 PM, Brendan Eich wrote: > On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote: > >> The Iterators proposal includes the definition >> (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of >> functions that are intended to support various common iteration patterns. >> >> For example, >> >> for ((k of keys(x)) { ...} >> for (v of values(x)) { ...} >> for ([k,v] of items(x)) {...} >> for (k of allKeys(x)) { ...} >> for (k of allValues(x)) { ...} >> for (i of allItems(x)) { ...} >> >> The use of these functions seems to be pretty much an essential part of the >> intended use of the for-of statement. > > The prior question is what, if anything, > > for (x of y) ... // and [x for x of y], etc. > > means. > > Should it throw if there's no @iterator private-named property in y *and* y > is not a Proxy with an iterate trap? That is our current thinking. It may not > be reflected well in the wiki. Another possibility would be to build in default @iterator methods on Object.prototype and Array.prototype. I'd probably make the object implementation be an items for enumerable properties and the array implementation iterate the values of 0..length-1 . > > The alternative is to iterate over property values of an object denoted y > that has no unstratified @iterator or stratified handler iterate trap. But > that is hostile to collections and your [] proposal. Property values (without key identification) doesn't sounds that generally useful. > > OTOH I see no problem for collection writers if we make for-of throw on > untrapped objects. Collection authors would bind @iterator, @elementGet, and > @elementSet. Life would be grand. Right? Yes, suspect that people defining collections would routinely want to over-ride @iterator. However, the defaults probably do establish some expectations. Particularly if we aren't providing many (any?) built-in collections that might establish other expectations. allen > > /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 14, 2011, at 9:07 AM, Allen Wirfs-Brock wrote: > On Nov 12, 2011, at 12:05 PM, Brendan Eich wrote: > >> On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote: >> >>> The Iterators proposal includes the definition >>> (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of >>> functions that are intended to support various common iteration patterns. >>> >>> For example, >>> >>> for ((k of keys(x)) { ...} >>> for (v of values(x)) { ...} >>> for ([k,v] of items(x)) {...} >>> for (k of allKeys(x)) { ...} >>> for (k of allValues(x)) { ...} >>> for (i of allItems(x)) { ...} >>> >>> The use of these functions seems to be pretty much an essential part of the >>> intended use of the for-of statement. >> >> The prior question is what, if anything, >> >> for (x of y) ... // and [x for x of y], etc. >> >> means. >> >> Should it throw if there's no @iterator private-named property in y *and* y >> is not a Proxy with an iterate trap? That is our current thinking. It may >> not be reflected well in the wiki. > > Another possibility would be to build in default @iterator methods on > Object.prototype and Array.prototype. I'd probably make the object > implementation be an items for enumerable properties and the array > implementation iterate the values of 0..length-1 . Not a bad set of defaults if Object.prototype was not a prototype of Array.prototype, and I was inclined the same way once upon a time. But then Jason (cc'ed) made a good argument (which I resisted fiercely at first because of the obvious utility of the defaults) that doing so in ES.next means anyone customizing collection iteration later will break generic code that wants only items, or only values. Really, JS is different from Python in this way: Array and Object are more like list+object and dict+object hybrids, and in Python class instances (objects) throw without a custom __iter__. They do not act like lists or dicts. Generic code will suffer, and type confusion bugs will tend to be more common ceteris paribus, if we do what you suggest. I tried patching the defaults to be value-only iteration. That still is future-hostile to evolving collection @iterator settings, but it's better. > Yes, suspect that people defining collections would routinely want to > over-ride @iterator. However, the defaults probably do establish some > expectations. Particularly if we aren't providing many (any?) built-in > collections that might establish other expectations. We might need to do some work there, with the community and prototype implementations. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Mon, Nov 14, 2011 at 09:07, Allen Wirfs-Brock wrote: > Another possibility would be to build in default @iterator methods on > Object.prototype and Array.prototype. I'd probably make the object > implementation be an items for enumerable properties and the array > implementation iterate the values of 0..length-1 . Defining @iterator on Object.prototype seems like it would be a disservice to future js programmers. It would basically turn the for-of loop into another reflection based loop and we would be back to square one. I'm in favor of Array.prototype.@iterator though -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 14, 2011, at 11:59 AM, Erik Arvidsson wrote: > On Mon, Nov 14, 2011 at 09:07, Allen Wirfs-Brock > wrote: >> Another possibility would be to build in default @iterator methods on >> Object.prototype and Array.prototype. I'd probably make the object >> implementation be an items for enumerable properties and the array >> implementation iterate the values of 0..length-1 . > > Defining @iterator on Object.prototype seems like it would be a > disservice to future js programmers. It would basically turn the > for-of loop into another reflection based loop and we would be back to > square one. > > I'm in favor of Array.prototype.@iterator though Yes, good point! I forgot to say that in my last reply. That seems unproblematic since anything delegating to Array.prototype should be array-like in wanting for-of to iterate values in index order, skipping holes. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Sun, Nov 13, 2011 at 12:17 PM, Erik Arvidsson wrote: > Another thing to consider is whether these functions belong in an iter > module or in a reflect module? I'm leaning towards the letter. I completely agree. for-of should be the tool for iterating over collections. We should make it super easy to get a collection of an object's properties. The right name for that facility is @reflect or @inspect, not @iter. The appropriate Python analog is the inspect module, not itertools. http://docs.python.org/library/inspect.html -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
To address Allen's original question: I think the Map and Set classes in Harmony mean that not all structured data is stored as object properties. I think that's a good thing. However it does mean that we must have a separation of concerns between - iterating over a collection - object property inspection ...because I don't see how 'for (p of obj)' can be both the right syntax for walking an arbitrary object's properties *and* the right syntax for walking a Set's elements. Someday the "arbitrary object" will be a Set. And then what? So if we take that separation of concerns as our maxim, what do we end up with? Here's a sketch. Basics: for (v of arr) // each element of an Array for (v of set) // each value in a Set for (k of map) // each key in a Map, following Python Host objects / libraries: for (elt of document.getElementsByTagName('P')) // DOM for (elt of $("div.main p")) // hypothetical jQuery support Other styles of iteration: for ([i, v] of arr.items()) // index-value pairs (new Array method) for ([k, v] of map.items()) // key-value pairs for (v of map.values()) // just values, no keys (uncommon use case) Enumerating properties: import * from '@inspect'; for (p of keys(obj)) for (v of values(obj)) for ([p, v] of items(obj)) Or if you don't want to import anything: for (p of Object.keys(obj)) for (p of Object.getOwnPropertyNames(obj)) This makes Map slightly nicer to iterate over than Object. I think Map is a better, less error-prone Map than Object anyway, so that's appropriate. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard @iter module unfriendly to collection builders
On Nov 15, 2011, at 1:42 PM, Jason Orendorff wrote: > On Sun, Nov 13, 2011 at 12:17 PM, Erik Arvidsson > wrote: >> Another thing to consider is whether these functions belong in an iter >> module or in a reflect module? I'm leaning towards the letter. > > I completely agree. > > for-of should be the tool for iterating over collections. > > We should make it super easy to get a collection of an object's properties. > > The right name for that facility is @reflect or @inspect, not @iter. > The appropriate Python analog is the inspect module, not itertools. > http://docs.python.org/library/inspect.html I defer to you, oh Python master. ;-) But still, @reflect is gonna be big. Arguably a bunch of things in JS from day 1 up through ES5.1 should go there, or appear there in better and more stylish clothes. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss