4 ms·
You could use grep() instead of filter(). Sorry for not including it in my first post... Granted, it still suffers the problem of lacking the shortcut, but pro
by Xurinos 17y ago
You could use grep() instead of filter(). Sorry for not including it in my first post... Granted, it still suffers the problem of lacking the shortcut, but programming new useful abstractions is part of our job anyway. The point is to make it readable.
I am skeptical that this example proved the thesis: "What is there you can't do with lambdas such that you need to add blocks?" unless the point was that you have the "benefit" of performing a goto/return out of a block and not out of a strictly scoped lambda. It seems like a step backward to me. For this example anyway, the better abstraction would be any() -- to treat the set of gestures as a queryable entity and to react to that query.
I haven't played with ruby in years, so forgive my syntax mistakes, but I do not think people would find
i = 0
something_or_other.each do |e|
return i if null(e)
i++
end
to be a better abstraction than
return e.length
Come to think of it, you have another return path downstream in that function anyway (not 'close').
return jQuery.any(collection, tester) ?
'close' :
'other value';
I am still open to the possible usefulness of blocks.
- lhorie 17y agoOne pattern that comes to mind: while (true) { if (testState()) return valueOfState(); } moreStateChangingStuff() as opposed to: var flag = false, result = null; loop(function() { if (testState()) { flag = true result = valueOfState() } }) if (flag) return result moreStateChangingStuff()
- raganwald 17y agoFor me it comes down to this: If the language uses blocks for its own constructs, it ought to let you use blocks for yours. If blocks are a bad idea for your constructs, then they ought to be a bad idea for `if` and `for` and all the other constructs languages like Javascript provide that have blocks of their own.