Path: csiph.com!weretis.net!feeder4.news.weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: filter queryselectorall Date: Sun, 07 Aug 2016 21:16:04 +0200 Organization: PointedEars Software (PES) Lines: 136 Message-ID: <1753248.oMNUckLgyt@PointedEars.de> References: <1547678.NO00hCYTYS@PointedEars.de> <1546201.XMfzL8yDUt@PointedEars.de> <792aba7d-dad5-48f2-abbc-08beaf9a69ad@googlegroups.com> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1470597366 26986 eJwFwYEBwDAEBMCV4vEYR0X2H6F3rhROGJ3mz18owI7Na8/ARc02b7lg78j5sqCBgwDRKT8RBhBB (7 Aug 2016 19:16:06 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Sun, 7 Aug 2016 19:16:06 +0000 (UTC) User-Agent: KNode/4.14.2 X-NNTP-Posting-Host: eJwNwoERwCAIBLCVUOQp48Aj+49gLzHFAv3AcGx+IUW2Zrb2LvP1XdSNnor241I7dUAOKcp5OUISeg== X-User-ID: eJwFwYEBwCAIA7CXRFoq5zCR/09YQg+LKwQDHM439RJ1aF1K21wq6BIWOy0au8mRt5S4T6vmlOshbBa9fkQTFN0= Xref: csiph.com comp.lang.javascript:31095 Michael Haufe (TNO) wrote: > […] Thomas 'PointedEars' Lahn wrote: >> Michael Haufe (TNO) wrote: >> > More like a pin-hammer. This is a general solution to the problem of >> > manipulating NodeLists, not solving this particular problem. The >> > alternative formulation, to avoid a potential compilation step for >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> How so? > > The common habit is to write JavaScript to target the least common > denominator of support: namely ES3 or ES5. Hence my example and more-so > yours. Those are *examples*. Unless news syntax is concerned (and even then, but at the cost of runtime efficiency and perhaps even security – eval(…)), there is no requirement to target the least common denominator: with proper feature testing, one can support *all* implementations suitable in that regard. Indeed, unless determining support is the goal, it is usually better to “polyfill” and use the polyfill so that the polyfill can be removed once all target environments support the native feature. (This recommendation does not apply to host objects.) > I take the position that one should write in the latest standard > version and compile to the lowest common denominator instead. Web > Developers aren't quite there yet in their personal workflow though and > many common libs may not be prepared properly for use (using global > variables and fake namespaces vs. modules). We have discussed this elsewhere and disagree about this. I do not think it is a good idea to use the latest/an extended version of a programming language just for the sake of it. Code that needs to be transpiled to backwards-compatible code not only adds the transpiler as a dependency; it can be a lot less efficient than if a simpler, more traditional pattern had been used that would not require a transpiler. One must ask oneself the question if the “syntactic sugar” is really worth it. >> Another problem is creating an Array instance unnecessarily. >> (“[].filter” is just the short form. Creation of an Array instance >> before filtering can be avoided entirely by holding the value of >> “Array.prototype” or “Array.prototype.filter” in a variable and re-using >> it as needed.) > > I would rather defer to Array.from, but yes, if I wanted to micro-optize: > > var filter = (xs,fn) => Array.prototype.filter.call(xs,fn) [For example, I found the advantage of that syntax over var filter = function (xs, fn) { return Array.prototype.filter.call(xs, fn); } to be negligibly small. The latter is even clearer than the former: I do not have to look closely to know that .filter() is not .call()ed before the anonymous function is called.] In any case, this is not a good idea because it requires resolution of “Array.prototype.filter” along the scope chain every time the filter function is called. It is not micro-optimization, but *de*optimization. Use instead: /* cache _once_ */ var filter = Array.prototype.filter; > var isEven = (x) => x % 2 == 0 > var xs = [1,2,3,4,5] > filter(xs,isEven) filter.call(xs, isEven); > /* 2,4 */ > > Even better if the standards bodies would align better and fix this mess > of an inheritance model. > > NodeList extends Array or somesuch... We (but IIRC not the two of us) have discussed this before. The DOM is designed to be a *language-independent* API, therefore it does not make sense for a DOM *interface* to extend a *prototype* of *one* particular programming language (here: ECMAScript). Historically, the DOM approach has been the other way around: Language binding was specified so that in certain programming languages features of the DOM were easier to use. For example, if “list” refers to an object implementing the NodeList interface, you can write “list[1]” instead of “list.item(1)” in ECMAScript implementations because the language binding section of the DOM Specification says so. However, the goals of DOM4 (REC as of 2015-11-19) explicitly include ,- | | · Aligning [previous Web API Specifications] with the JavaScript ecosystem | where possible. and DOM4 calls DOM Level 3 Core “non-normative”. That would include the ECMAScript Language Binding. The aforementioned simplification is no longer specified by language binding in DOM4 but simply as alternative syntax (with no reference to “JavaScript” whatsoever). (From this we can assume that inheritance from Array.prototype was not possible if the DOM was to be kept language-indepent.) Now, DOM *implementations* MAY decide to implement the inheritance that you wish for. But be careful what you wish for: This would create a potential for naming conflicts when the DOM interface specifies attributes or methods whose names are already in use in ECMAScript or the document. For HTMLCollection the situation is worse than NodeList as a conforming ECMAScript implementation must not distinguish between property access by brackets and by dot, which DOM2+ allow instead of calling the .namedItem() method with the name/ID as argument. Even if “the standards bodies would align better” they could not solve the problem of unforeseen element names or IDs to the satisfaction of all people involved: for example, if HTMLCollection inherited from Array.prototype, none of the names of inherited properties could be used as element names or IDs by authors; otherwise they would override those attributes and methods. Such misguided attempts by API designers have already been made and the mistakes are still causing problems today: because of HTMLFormElement::submit() and the “form.elements["bar"] → form.bar” access shortcut introduced in DOM Level 0, one must not name any control in that form "submit" or the method becomes unavailable; even removing such an element on submit does not restore the method, but leaves the property value to be “undefined”; IOW, not callable. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.