Perhaps, as _why's Poignant Guide, the poet goes too far: and then we lose too much substance. But 150 pages? Au revoir: there must be a cleaner, deeper essence. For I delight in the everyday code, which is fun, dramatic, sweeping, and wry, and manufactured examples of jQuery's road are nowhere as cool as an eval/apply.
The worst part is, he knows not what he does. For I opened him up to a random page, and saw what he said -- and I don't mean to fuss, but I can't help but feeling a little rage:
The Iterator Pattern is a design pattern where iterators (objects that allow us to traverse through all the elements of a collection) access the elements of an aggregate object sequentially without needing to expose its underlying form.
Iterators encapsulate the internal structure of how that particular iteration occurs - in the case of jQuery's $(el).each() iterator, you are actually able to use the underlying code behind $.each() to iterate through a collection, without needing to see or understand the code working behind the scenes that's providing this capability. This is a pattern similar to the facade, except it deals explicitly with iteration.
No, my good sir, ten times no. The iterator pattern as was discussed (in Design Patterns, and such and so), has nothing to do with that construct. Iterators speak polymorphism out loud, freeing us from finities and the rest of the crowd. Let me illustrate with a simple collection of rational numbers -- in Cantor's bijection:
function gcd(lo, hi) {
return lo > hi ? gcd(hi, lo) : lo === 0 ? hi : gcd(hi % lo, lo);
}
function rational_iterator() {
var num = 0, denom = 1;
return {
hasNext: function () {
return true;
},
next: function recurse() {
var rat = [num, denom];
if (denom === 1) {
denom = num + 1;
num = 1;
} else {
denom -= 1;
num += 1;
}
return gcd(rat[0], rat[1]) === 1 ? rat : recurse();
}
};
}
And perhaps arrays are not quite your style, so you might like me to convert them to strings. That requires a new map method -- I'm not in denial -- but that's pretty simple in the grand scheme of things:
function map(seq, fn) {
var i = 0;
return {
hasNext: function () {
return seq.hasNext();
},
next: function () {
return fn(seq.next(), i++);
}
};
}
var rationals_as_strings = map(rational_iterator(), function (x) { return x.join("/"); });
Our lazy maps and infinite sequence save us from any pro-jQuery pretense and instead show us a taste of that vision of knowing your code, with modest concision.
> No, my good sir, ten times no. The iterator pattern as was discussed (in Design Patterns, and such and so), has nothing to do with that construct. Iterators speak polymorphism out loud, freeing us from finities and the rest of the crowd.
That is not entirely true, internal iterators in the style of Smalltalk and Ruby have all the capabilities of GOF-style external iterators, and jQuery (or underscore's) each is a restricted kind of internal iterator.
And while that is (sadly) not supported at the moment these could very well delegate to an arbitrary implementor of Javascript's own internal iterator protocols (JS 1.6's "Array extras"), leading exactly to the capabilities you describe (including but not limited to polymorphism).
Furthermore, external iterators are of little use, value and class when you have blocks, or at least "full" anonymous functions. It's unsurprising to have them in the C++ and Java-based GOF, but they don't belong anywhere near JavaScript.
I defer to him who made a plea, for consultants' reports to become poetry: https://www.youtube.com/watch?v=GUSLEJB9_LU
Perhaps, as _why's Poignant Guide, the poet goes too far: and then we lose too much substance. But 150 pages? Au revoir: there must be a cleaner, deeper essence. For I delight in the everyday code, which is fun, dramatic, sweeping, and wry, and manufactured examples of jQuery's road are nowhere as cool as an eval/apply.
The worst part is, he knows not what he does. For I opened him up to a random page, and saw what he said -- and I don't mean to fuss, but I can't help but feeling a little rage:
The Iterator Pattern is a design pattern where iterators (objects that allow us to traverse through all the elements of a collection) access the elements of an aggregate object sequentially without needing to expose its underlying form.
Iterators encapsulate the internal structure of how that particular iteration occurs - in the case of jQuery's $(el).each() iterator, you are actually able to use the underlying code behind $.each() to iterate through a collection, without needing to see or understand the code working behind the scenes that's providing this capability. This is a pattern similar to the facade, except it deals explicitly with iteration.
No, my good sir, ten times no. The iterator pattern as was discussed (in Design Patterns, and such and so), has nothing to do with that construct. Iterators speak polymorphism out loud, freeing us from finities and the rest of the crowd. Let me illustrate with a simple collection of rational numbers -- in Cantor's bijection:
And perhaps arrays are not quite your style, so you might like me to convert them to strings. That requires a new map method -- I'm not in denial -- but that's pretty simple in the grand scheme of things: Our lazy maps and infinite sequence save us from any pro-jQuery pretense and instead show us a taste of that vision of knowing your code, with modest concision.