

John Resig: Unimpressed by NodeIterator - mbrubeck
http://ejohn.org/blog/unimpressed-by-nodeiterator/

======
tolmasky
I agree with all the points here except for the part about bit flags. Bit
flags are still arguably the best way to store "sets" of non-duplicate
information. For example, if I wanted to aggregate the kinds of nodes I'd want
with John's API, I'd have to accumulate them in an array, then use apply()
because I can't pass that array in. Then there's the problem of duplicates,
and also easily being able to check, add, and remove. All these operations are
of course possible with an array (even if they contain duplicates), but it
seems a bit much to go down a route where all these operations are inherently
O(N) when there is an O(1) solution that isn't _that_ hard to learn.
Additionally you can easily construct shorthands for often used combinations:
ElementsAndText = Element | Text. In the array world, you're going to be
having to concat arrays to achieve a similar effect. It's also really nice
that you can say "ALL" just with 0xF...FFFF (-1) and be assured that it is
future proof, whereas in the array world if new nodes creep in in the future,
you have to now go back to every instance where you called this and add a new
parameter. I suppose the "easy" fix for this is to just say that if nothing is
passed in it means "all", or alternatively have an ALL constant.

We recently tackled a similar issue in Cappuccino and our solution was to
create two parallel ways of specifying this information that were
transparently convertible: a pure bit flags version and a strings version,
such that (Selected | Highlighted) is equivalent to "selected+highlighted".
You can pass in either the string form or the bit form to the methods, and you
can convert between them as well. All in all, none of the "JS people" using
our framework seemed to mind the use of bit flags.

~~~
tc
We're talking about JavaScript, so Scheme is a better example than C. At the
level of abstraction Javascript deals in, bit twiddling like this should not
be necessary. Even using all caps constants just feels dirty. And JavaScript
isn't even any good at bit twiddling, as it doesn't use native machine
integers.

------
andreyf
Sure, but aren't you the guy whose claim to fame is taking DOM API's written
by people who think in C++ and translating them into JavaScript? Get to work!

------
moe
This is a nice example for the (not so) subtle brain damage that java has
inflicted upon a whole generation of developers. John points out nicely how
the insanity even creeps into other languages when nobody's looking...

~~~
andreyf
I think here C++ is more likely culprit.

------
prodigal_erik
He's right about this rightfully being a node method rather than a document
method. But if the common developer can't understand bit flags, I don't think
they are going to have a long career. And I can't think of a good reason to
use entityReferenceExpansion=false unless you're going out of your way to
handle entities yourself (which he's clearly not inclined to do).

~~~
jeresig
The common developer or the common web developer? I think most web developers
can go very far without ever using bit flags - especially considering that no
common JavaScript or DOM APIs use them.

"And I can't think of a good reason to use entityReferenceExpansion=false..."
It's all about the element of least surprise - are developers more likely to
expect the syntax that they see on the page (e.g. &foo;) or something else in
its place. Whatever the right answer is to that question should be made the
default option and left as that.

