> I fully agree. I don't like grab, nor do I like the element getters except
> getElements.
FWIW... I'm quite comfortable with the easily-understood separation
and meaning of most of these methods, as opposed to overloading a
single method and/or requiring an object to simulate named parameters.
For example, I often use getEls and getChildren with no params. If you
combine these:
· it might be getAnything(selector,depth) which means I have to pass a
null/empty selector half the time, and the method isn't
self-explanatory with the unnamed second param
· if it's getAnything({[selector:selector],[depth:depth]}) where every
non-default is a named param, well, just looks inelegant to me
· if it's using type detection, like getAnything([string
Selector],[object Options{[depth:depth]}]), I see how that would be
the most streamlined from an API standpoint since we could still have
at least some chance of using simple syntax, but it seems like a lot
of work for you, with not enough payoff
Is there another tack that you guys have in mind?
I see methods with a limited number of params, and separation of
methods by return value, as pretty common and comfortable JS/DOM
paradigms. Look at querySelector and querySelectorAll. As far as I can
read in the WHATWG logs, which are of course very recent, there wasn't
any serious suggestion of querySelector([all=false]). Or take the
xxxx/xxxxNS pairs.
As for adopt() and grab(), I admit I never use grab(), but as long as
core methods like apply() and call() are both still around, I don't
find this so bad. If anything, it makes Moo seem like a seamless
extension of core JS, keeping you aware of your surroundings. I like
that!
We'll live with whatever changes you make, but it doesn't seem so
out-of-whack to me.
-- Sandy
