Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31095

Re: filter queryselectorall

Show all headers | View raw

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.

<https://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>

However, the goals of DOM4 (REC as of 2015-11-19) explicitly include

,-<https://www.w3.org/TR/2015/REC-dom-20151119/#goals>
| 
| · 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: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

filter queryselectorall Andrew Poulos <ap_prog@hotmail.com> - 2016-08-06 14:25 +1000
  Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-05 22:23 -0700
    Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-06 08:16 +0200
      Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-06 15:49 -0700
        Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:08 +0200
          Re: filter queryselectorall Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-08-07 07:17 +0200
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:58 +0200
          Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-07 10:30 -0700
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 21:16 +0200
              Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-09 21:18 -0700
                Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-15 22:02 +0200
                Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-15 23:16 -0700
  Re: filter queryselectorall "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-08-06 10:28 +0200

csiph-web