Why not NodeList#forEach :\?
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ?
I've written a section on MDN specifically a while ago to answer that very question: developer.mozilla.org/En/DOM/NodeList#Why_can't_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the language (syntax, semantics, etc.), while NodeList are part of the DOM which can be considered as an ECMAScript library. However, of course, browsers all ship this "library" by default. It is however not present in server-side environments like Node.js. A longer time ago, I wrote another page to describe what "JavaScript" mean, because it has become an umbrella term to talk about a lot of different technologies: developer.mozilla.org/en/JavaScript_technologies_overview
Thank you very much for the clarification! Also noticed 'Extending the DOM is dangerous.'
On Monday, June 11, 2012 at 6:30 AM, Hemanth H.M wrote:
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ?
ES6 draft specifies a new Array constructor called Array.from that will essentially convert "array-likes" into arrays:
Array.from( nodes ).forEach(...
Wow, that's interesting. When will that be implemented?
Le 11/06/2012 14:56, Hemanth H.M a écrit :
Wow, that's interesting. When will that be implemented?
Depends on browsers. Good news is that you can polyfill it today! :-) Actually, that could be a good fit for paulmillr/es6
ES6 draft specifies a new Array constructor called Array.from that will essentially convert "array-likes" into arrays
This will have uses for the arguments objects too, for people that aren't using ...rest in ES6.
Tom
Uber kool! Thanks a ton David!
npm install es6-shim # wow :) Shall blog about this!
Well, Map() and Set() is already there is FF13, it's an experimental API right? Experimental means it can be chucked off or it shall be modified drastically ? ( More Java like APIs :\ )
Well {} behaved liked map and well for sets we can use [].sort.filter( function(v,i,o){return v!==o[i-1];}
Le 11/06/2012 15:13, Hemanth H.M a écrit :
Uber kool! Thanks a ton David! |npm install es6-shim # wow :) Shall blog about this!
| Well, Map() and Set() is already there is FF13, it's an experimental API right? Experimental means it can be chucked off or it shall be modified drastically ? ( More Java like APIs :\ )
Well {} behaved liked map and well for sets we can use [].sort.filter(function(v,i,o){return v!==o[i-1];}
The major use case for Maps and Sets (as far as i'm concerned) is the ability to use objects as keys. Having built-in implementation of these potentially enable O(1)-ish lookups (which is impossible to implement in JavaScript). As to Maps and {} being equivalent, that's true expect when it's not, like when you want to use pseudo properties like proto or noSuchMethod as keys. Some folks tried to use objects as maps and got burned [1]. See Caja's StringMap [2] for a workaround when you only need strings as keys.
David
[1] productforums.google.com/forum/#!topic/docs/0hQWeOvCcHU [2] code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/StringMap.js
Le 11/06/2012 15:23, Hemanth H.M a écrit :
Ha Hmm, yet to |iterate| sets
For...of loop may be of some help here. Good introductory article by Axel Rauschmayer from this morning (doesn't talk about Sets, but it should work I think): www.2ality.com/2012/06/for-of-ff13.html
On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis <tellishtc at gmail.com> wrote:
ES6 draft specifies a new Array constructor called Array.from that will essentially convert "array-likes" into arrays
This will have uses for the arguments objects too, for people that aren't using ...rest in ES6.
Indeed - Array.from can be used with any object that has a numeric index and length property whose value is a number - which covers a very wide swath of Ecmascript/non-Ecmascript objects.
Thank you Rick Waldron :)
BTW tired 'es6-shim' on node.js and :
Math.sign(-0)
-1 Should it give an error?
Awesome. I've had es6-shim for a while now but I haven't used it yet. I forgot what its use was until now.
Tom
On Jun 11, 2012, at 7:00 AM, Hemanth H.M wrote:
Thank you Rick Waldron :)
BTW tired 'es6-shim' on node.js and :
Math.sign(-0)
-1
Should it give an error?
You could find the answer to that by checking the draft specification at harmony:specification_drafts
See section 15.8.2.31
Not quite impossible, you just have to get a bit creative. While certainly not as fast as a built in implementation, the method used here is still O(1). Benvie/ES6
Le 11/06/2012 19:21, Brandon Benvie a écrit :
Not quite impossible, you just have to get a bit creative. While certainly not as fast as a built in implementation, the method used here is still O(1). Benvie/ES6-Harmony-Collections-Shim
After studying the code, my analysis of it is that the complexity of lookup and insertion in the weakmaps is the complexity of lookup and insertion of properties in objects. An implementation which has O(n) for object properties operations will yield a O(n) for your weakmaps and so on. But it's very likely that all modern implementations have hashmaps for that, so indeed O(1)-ish.
For anyone who hasn't read the code yet, I recommand reading it; I found it very instructive. I particularly enjoyed the "keystore = Object.create.bind(null, null)".
On Jun 11, 2012, at 11:46 AM, David Bruant wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ? I've written a section on MDN specifically a while ago to answer that very question: developer.mozilla.org/En/DOM/NodeList#Why_can't_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the language (syntax, semantics, etc.), while NodeList are part of the DOM which can be considered as an ECMAScript library. However, of course, browsers all ship this "library" by default. It is however not present in server-side environments like Node.js. A longer time ago, I wrote another page to describe what "JavaScript" mean, because it has become an umbrella term to talk about a lot of different technologies: developer.mozilla.org/en/JavaScript_technologies_overview
Be that as it may, the intent of the new elem.find() API is to give us a chance to fix this (among other) errors in DOM's design. Yes, it's up to DOM to fix it, but we need ES to adopt things like Allen's Object Model Reformation to help enable it:
Le 19/06/2012 14:11, Alex Russell a écrit :
On Jun 11, 2012, at 11:46 AM, David Bruant wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ? I've written a section on MDN specifically a while ago to answer that very question: developer.mozilla.org/En/DOM/NodeList#Why_can't_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the language (syntax, semantics, etc.), while NodeList are part of the DOM which can be considered as an ECMAScript library. However, of course, browsers all ship this "library" by default. It is however not present in server-side environments like Node.js. A longer time ago, I wrote another page to describe what "JavaScript" mean, because it has become an umbrella term to talk about a lot of different technologies: developer.mozilla.org/en/JavaScript_technologies_overview Be that as it may, the intent of the new elem.find() API
Where is this API defined (or being discussed)? I don't recall anything about that in ECMAScript proposals/strawmen and I can't find it in the latest DOM4 draft.
is to give us a chance to fix this (among other) errors in DOM's design. Yes, it's up to DOM to fix it, but we need ES to adopt things like Allen's Object Model Reformation to help enable it:
I guess knowing what the elem.find() API is will help me understand this part better, because I'm not sure I see the link between the object model reformulation and fixing the DOM API. Can you elaborate further on that? (if this discussion already happened somewhere else, a link to that discussion will be enough, of course)
Meanwhile, when you say "us" or "we", who are you referring to? The "es-discuss" folks, TC39, the DOM APIs folks, web devs interested in standards, another group?
On Tuesday, June 19, 2012 at 8:29 AM, David Bruant wrote:
Le 19/06/2012 14:11, Alex Russell a écrit :
On Jun 11, 2012, at 11:46 AM, David Bruant wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ?
I've written a section on MDN specifically a while ago to answer that very question: developer.mozilla.org/En/DOM/NodeList#Why_can't_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the language (syntax, semantics, etc.), while NodeList are part of the DOM which can be considered as an ECMAScript library. However, of course, browsers all ship this "library" by default. It is however not present in server-side environments like Node.js. A longer time ago, I wrote another page to describe what "JavaScript" mean, because it has become an umbrella term to talk about a lot of different technologies: developer.mozilla.org/en/JavaScript_technologies_overview
Be that as it may, the intent of the new elem.find() API
Where is this API defined (or being discussed)? I don't recall anything
about that in ECMAScript proposals/strawmen and I can't find it in the
latest DOM4 draft.
lists.w3.org/Archives/Public/public-webapps/2011OctDec/1454.html
I guess we can try to push Web IDL to do this.
2012/6/11 Hemanth H.M <hemanth.hm at gmail.com>:
On Jun 19, 2012, at 5:29 AM, David Bruant wrote:
Le 19/06/2012 14:11, Alex Russell a écrit :
...
is to give us a chance to fix this (among other) errors in DOM's design. Yes, it's up to DOM to fix it, but we need ES to adopt things like Allen's Object Model Reformation to help enable it:
strawman:object_model_reformation I guess knowing what the elem.find() API is will help me understand this part better, because I'm not sure I see the link between the object model reformulation and fixing the DOM API. Can you elaborate further on that? (if this discussion already happened somewhere else, a link to that discussion will be enough, of course)
Actual API "design" is probably an orthogonal issue. What the "Object Model Reformation" proposal (which is probably better understood by its subtitle "Decoupling [ ] and Property Access") does is permit the existing behavior of DOM collections to be directly expressed in JavaScript without having having to resort to host object magic. It supports the general principle of: If the DOM needs to do it then it should be doable in pure JavaScript. There are lots of reasons why for some objects it makes sense for "indexed access" to have different semantics than "property access". The DOM does this today. In an improved DOM API design it will probably also be the case. The Object Model Reformation provides a semantic basis for designing such improved APIs rather than just making up host object magic that has no foundation in core JavaScript semantics.
On Tue, Jun 19, 2012 at 6:42 AM, 程劭非 <csf178 at gmail.com> wrote:
I guess we can try to push Web IDL to do this.
WebIDL provides [ArrayClass] and DOM4 make NodeLists ArrayClass. This means that NodeLists have Array.prototype on its prototype chain.
We tried to make this change in WebKit but it caused some issues, mostly on sites depending on a bug in Closure Library. The Closure bug has been fixed but the question is how many other sites out there do incorrect detection and therefore assume that anything that is an instance of Array is actually a true Array
My plan is to try again on Chrome Dev channel in the near future and see if we have better luck this time.
When I made that one : Ayms/node-dom it was supposed to be a fast and minimal implementation of the DOM, so it works in almost all real cases and do not crash in other situations.
The result is not bad but not as fast as expected neither minimal. Not minimal because I had to adapt to plenty of frameworks or sites's specific stuff but widely used. Not as fast as expected because I think property access is too slow (styles lookup for example for this project, it seems that the problem increases exponentially when trying to access undefined properties), I thought maybe it would be possible to implement virtual rendering but I had to surrender, no way today to do this in js I believe, it would be too slow, but maybe tomorrow if I read correctly this thread.
Regarding NodeLists, it's not an ES subject but I would say :
1- the "world" thinks it is an array 2- the "world" does not know it is updated dynamically (in an "ordered" way in addition ...)
As everybody I made my own NodeList (and other things such as CSSStyleDeclaration), not exactly w3c, which is to make it look like an array (like everybody again and future DOM specifications), so 1) is solved
But 2) (which is the dynamic "ordered" update of NodeLists) still continues to look useless to me and a huge handicap for performances, I suppose plenty of people will disagree, probably a question of experience, unlike jquery for example I never or rarely uses/used NodeLists and probably jquery users or just normal developers recall several time $('xx') or document.getElement(s)Byxxx, the question here has nothing to do with ES but is it really fundamental ?
Le 19/06/2012 17:37, Allen Wirfs-Brock a écrit :
Le 19/06/2012 18:21, Erik Arvidsson a écrit :
On Tue, Jun 19, 2012 at 6:42 AM, 程劭非 <csf178 at gmail.com> wrote:
I guess we can try to push Web IDL to do this. WebIDL provides [ArrayClass] and DOM4 make NodeLists ArrayClass. This means that NodeLists have Array.prototype on its prototype chain.
Excellent! I hadn't heard of that.
We tried to make this change in WebKit but it caused some issues, mostly on sites depending on a bug in Closure Library. The Closure bug has been fixed but the question is how many other sites out there do incorrect detection and therefore assume that anything that is an instance of Array is actually a true Array
I'll guess a quantity between "a lot" and "a ridiculous amount". I read "if(something instanceof Array)" very often when view-sourcing and they mean "Array.isArray(something)". A trickier question is: will this code break the NodeLists inherit from Array.prototype and that's harder to answer.
My plan is to try again on Chrome Dev channel in the near future and see if we have better luck this time.
Good luck! I wish it'll work!
On Tue, Jun 19, 2012 at 1:55 PM, David Bruant <bruant.d at gmail.com> wrote:
Le 19/06/2012 18:21, Erik Arvidsson a écrit :
On Tue, Jun 19, 2012 at 6:42 AM, 程劭非 <csf178 at gmail.com> wrote:
I guess we can try to push Web IDL to do this. WebIDL provides [ArrayClass] and DOM4 make NodeLists ArrayClass. This means that NodeLists have Array.prototype on its prototype chain. Excellent! I hadn't heard of that.
We tried to make this change in WebKit but it caused some issues, mostly on sites depending on a bug in Closure Library. The Closure bug has been fixed but the question is how many other sites out there do incorrect detection and therefore assume that anything that is an instance of Array is actually a true Array I'll guess a quantity between "a lot" and "a ridiculous amount". I read "if(something instanceof Array)" very often when view-sourcing and they mean "Array.isArray(something)". A trickier question is: will this code break the NodeLists inherit from Array.prototype and that's harder to answer.
The case that broke was something like this:
if (x instanceof Array) realArray.concat(x);
The problem is that concat behaves different when its argument is a real Array ([[Class]] is "Array").
I wonder if we could change concat in such a way that it checks the prototype chain too?
On Jun 19, 2012, at 3:20 PM, Erik Arvidsson wrote:
On Tue, Jun 19, 2012 at 1:55 PM, David Bruant <bruant.d at gmail.com> wrote:
Le 19/06/2012 18:21, Erik Arvidsson a écrit :
On Tue, Jun 19, 2012 at 6:42 AM, 程劭非 <csf178 at gmail.com> wrote:
I guess we can try to push Web IDL to do this. WebIDL provides [ArrayClass] and DOM4 make NodeLists ArrayClass. This means that NodeLists have Array.prototype on its prototype chain. Excellent! I hadn't heard of that.
We tried to make this change in WebKit but it caused some issues, mostly on sites depending on a bug in Closure Library. The Closure bug has been fixed but the question is how many other sites out there do incorrect detection and therefore assume that anything that is an instance of Array is actually a true Array I'll guess a quantity between "a lot" and "a ridiculous amount". I read "if(something instanceof Array)" very often when view-sourcing and they mean "Array.isArray(something)". A trickier question is: will this code break the NodeLists inherit from Array.prototype and that's harder to answer.
The case that broke was something like this:
if (x instanceof Array) realArray.concat(x);
The problem is that concat behaves different when its argument is a real Array ([[Class]] is "Array").
I wonder if we could change concat in such a way that it checks the prototype chain too?
I touched upon this in #5 of strawman:es5_internal_nominal_typing and in more detail in docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?authkey=CI-FopgC
Basically the way to fix it is to define a well known private name property that concat uses to determine the kind of target container to instantiate (for example, its value could be the constructor to invoke to create it).
Then things like NoteList.prototype could have that property defined such as to produce NodeList instances.
I probably need to write up a short strawman specifically about this.
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ?
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ? -- *'I am what I am because of who we all are'* h3manth.com <http://www.h3manth.com> *-- Hemanth HM * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120611/05f36877/attachment.html>