Re: Object model reformation?
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
Re: Object model reformation?
On 27 December 2012 05:53, Brendan Eich bren...@mozilla.com wrote: 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. Not often used =/= not often needed. Seriously, I contest your theory. I think such observations usually suffer from selection bias. In imperative languages, you see arrays used for almost everything, often to horrible effect. In the functional world many people seem to think that lists is all you need. In scripting languages it's often hashmaps of some form. I think all are terribly wrong. Every community seems to have its predominant collection data structure, but the main reason it is dominant (which implies vastly overused) is not that it is superior or more universal but that it is given an unfair advantage via very convenient special support in the language, and programmers rather shoe-horn something into it then losing the superficial notational advantage. Languages should try harder to get away from that partisanship and achieve egalite without baroque. But yes, ES is probably not the place to start fixing this. :) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object model reformation?
Andreas Rossberg wrote: On 27 December 2012 05:53, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: 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. Not often used =/= not often needed. True, and hard to prove. Seriously, I contest your theory. I think such observations usually suffer from selection bias. Definitely the big weakness of my theory. It's not mine alone of course, and it is not falsifiable _in situ_ or by simulation/reproduction, like a lab experiment. But my gut says there's something going on here beyond hashes-and-arrays selection bias. Hashes and arrays are strong in memory safe languages but one still sees other data structures evey in dynamically typed languages, especially the rise of functional data structures. What I do not see yet: more elaborate Collections APIs that were popular decades ago, but that do not scale well out of the d-cache. In imperative languages, you see arrays used for almost everything, often to horrible effect. In the functional world many people seem to think that lists is all you need. In scripting languages it's often hashmaps of some form. I think all are terribly wrong. JS hackers use objects and arrays, but also lately more map/fold-based stuff. At small scale its overhead doesn't matter, and with the right discipline it can scale up to very large working sets. We hope with RiverTrail and other research to go beyond that. I've seen v8-cgi-programmed 48 core boxes with global (slow) and local (to the core, but only that core) memory using this style, it can work with enough care. Every community seems to have its predominant collection data structure, but the main reason it is dominant (which implies vastly overused) is not that it is superior or more universal but that it is given an unfair advantage via very convenient special support in the language, and programmers rather shoe-horn something into it then losing the superficial notational advantage. Languages should try harder to get away from that partisanship and achieve egalite without baroque. That is a good reason for more languages and language innovation. JS ain't everything to all programmers, thank goodness. Mozilla is investing in Rust to elevate safety and concurrency beyond C++, and this requires new thinking (an ownership system with enough richness to capture all the safe-ish C++ idioms). But yes, ES is probably not the place to start fixing this. :) Not generally. However, the functional style is on the rise in JS, and we're pushing it farther with things like RiverTrail. It's not unthinkable that JS could evolve into a better eager/mutating functional language, with more functional data structures and fewer arrays and hashes in-the-large. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object model reformation?
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Is the object model reformation (OMR) still on the table for ES6? 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. -- 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
Re: Object model reformation?
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object Model Reformation – elementIn?
On Jan 1, 2012, at 5:54 AM, Axel Rauschmayer wrote: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Currently, there one can override the built-in operators via elementGet (getting via []), elementSet (setting via []) and elementDelete (`delete` operator). Wouldn’t it make sense to also provide elementIn (`in` operator)? Probably. It may depend upon how strongly you feel about obsoleting for-in in favor of for-of. Allen -- 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object Model Reformation – elementIn?
Currently, there one can override the built-in operators via elementGet
(getting via []), elementSet (setting via []) and elementDelete (`delete`
operator). Wouldn’t it make sense to also provide elementIn (`in` operator)?
Probably. It may depend upon how strongly you feel about obsoleting for-in
in favor of for-of.
That would be some kind of iteration protocol(?) I’d be perfectly happy with
not supporting for-in at all.
I was thinking about the relational operator `in`:
if (key in myMap) {
...
}
if (element in mySet) {
...
}
--
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
Object Model Reformation – elementIn?
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Currently, there one can override the built-in operators via elementGet (getting via []), elementSet (setting via []) and elementDelete (`delete` operator). Wouldn’t it make sense to also provide elementIn (`in` operator)? -- 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
