This article seems to be making up its own terminology and patterns. In JS, a getter is a function bound to a property that is called when that property is accessed. (mdn.io/getter) and a setter is a function bound to a property that is called when the property is set (mdn.io/setter). In JS there isn't any real differentiation you need to make between a function with 0 arguments, a function with 1 argument, and a function with N arguments. They're all functions with some arity that you can call.
This is a pretty interesting ontology of one path generalization.<p>I find the getter/setter nomenclature a little imprecise. It makes me think of interacting with fixed state, rather than input and output into completely abstract "systems" on the other side of the function calls. To me, provider/consumer seems a bit more on-the-mark.<p>It seems to me that there are other paths of generalization you could follow, as well (e.g. <a href="https://leanpub.com/combinators" rel="nofollow">https://leanpub.com/combinators</a>). Even though we all know that you can model...well...<i>anything</i> with functions, it's still enlightening and mindbending to explore the patterns for actually doing so.
> Writing the above code example with none of the abstractions in the Getter-Setter Pyramid requires more amount of code, which is also harder to read.<p><pre><code> let usersRange = (start, end, result, doneCb, errorCb) => {
let xhr = new XMLHttpRequest();
xhr.responseType = 'json';
xhr.open('GET', 'http://jsonplaceholder.typicode.com/users/' + start)
xhr.send();
xhr.onerror = ev => errorCb();
xhr.onload = ev => {
result.push(xhr.response);
if (start < end)
return usersRange(start + 1, end, result, doneCb, errorCb);
done(result);
}
};
usersRange(0, 10, [], /* completion callbacks */);
</code></pre>
Simpler, not really harder to read (half of it is just boilerplate around XHR setup, which is abstractable away). The meat of it is onload handler.
Similar in concept to the General Theory of Reactivity, GTOR: <a href="https://github.com/kriskowal/gtor/" rel="nofollow">https://github.com/kriskowal/gtor/</a>
I'm interested in this simple closure code from the article:<p><pre><code> function getGetNext() {
let i = 2;
return function getNext() {
const next = i;
i = i * 2;
return next;
}
}
</code></pre>
As a lisp coder [and not a JS coder], I'm wondering: why does the function getNext() have to be named? Why not just say something like:<p><pre><code> function getGetNext() {
let i = 2;
return function() {
const next = i;
i = i * 2;
return next;
}
}</code></pre>
There is a great talk by Erik Meijer (who invented Rx) showing this very neatly: <a href="https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-Duality" rel="nofollow">https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Ke...</a>
I thought this was going to be about lenses implemented in JavaScript, if it was I didn't get it. The Haskell lens[1] package (which implements a type of lenses referred to as van Laarhoven lenses after their discoverer Twan van Laarhoven) builds up a hierarchy (pyramid if you will) of lenses with varying degrees of generality and power.<p>[1]: <a href="http://hackage.haskell.org/package/lens-4.17#readme" rel="nofollow">http://hackage.haskell.org/package/lens-4.17#readme</a>
There is no copyright on terms 'getter', 'setter' etc.<p>For the first part I didn't like the article since it's somewhere between fp and oop, vague or foggy. But it's just my interpretation based/biased with previous knowledge.<p>Once I assumed the article is conceptual and in harmony with it's definitions, everything got much more sense.<p>I like it.
I'm sure the author knows more about the topic than me. However, it reads like someone trying to rationalize something that isn't quite rational.<p>IE: Walking into an old antique store and attempting to explain the genius logic behind it's organization. Shortly after the owner comes out and says, "No, I just throw shit wherever."
> The cornerstone of JavaScript is the function.<p>JavaScript is specified in terms of objects, has richer facilities for dealing with objects than functions, functions are objects but not vice-versa. So, objects are the cornerstone. Callers are free to ignore a function's arity even.
Is this the write-up of his talks?<p>I remember this one, from the Uphill Conference:
<a href="https://www.youtube.com/watch?v=fdol03pcvMA" rel="nofollow">https://www.youtube.com/watch?v=fdol03pcvMA</a>