Good points. I rarely (if ever) miss more powerful collections. I do miss more functionality along the lines of the standard libraries of functional programming languages. And I sometimes miss working with arrays of objects (or maps) like in relational calculus (or, possibly, LINQ). That last one is clearly beyond the scope of ECMA-262. More standard library things might not be (range, “reverse” the mappings of a map or an object, zip, etc.).
You don’t like the idea of read-only views? You’d rather copy? Even without that use case, faking arrays (without resorting to proxies) still seems useful, but that’s apparently considered for ES7 or later, anyway. On Dec 27, 2012, at 5:53 , Brendan Eich <bren...@mozilla.com> wrote: > Axel Rauschmayer wrote: >> http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation >> >> Is the object model reformation (OMR) still on the table for ES6? > > It never was -- it missed the cutoff by over five months. > >> The reason I’m asking is that I recently remembered a technique from the >> Java collections API: you could wrap any collection in a read-only “view”. >> That made it possible to have aliases to internal data structures without >> worrying about them being modified. The OMR would allow one to implement >> such wrappers for arrays. > > Java, schmava :-P. > > I have a theory: hashes and lookup tables (arrays or vectors) have displaced > most other data structures because most of the time, for most programs > (horrible generalizations I know), you don't need ordered entries, or other > properties that might motivate a balanced tree; or priority queue operations; > or similar interesting data structures we all studied in school and used > earlier in our careers. > > It's good to have these tools in the belt, and great to teach them, know > their asymptotic complexity, etc. > > But they just are not that often needed. > > So if JS grows a big collections API with some nominal-ish interface-like > faceting, I'll be surprised -- and disappointed. I don't think we need it. > This isn't that language. Those minority-use-case data structures are > usually one-offs. These aren't the hash-and-array droids you're looking for. > > Iteration protocols for collections? Sure, but don't fit all pegs into the > one octagonal hole. Lists want value iteration, dicts want [key, value]. > > Abstraction is two-edged, especially when piled up to handle "collections" > that might need to scale off of data cache memory. That's another point: if > you really want to scale in the modern world, you want functional data > structures, maps and folds, immutability. Abstracting at that level is cool > and people do it even in the small, in the dcache. Doesn't work the other > way, especially with mutation and eager effects. > > Anyone disagree strongly? > > /be > -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
