I applaud people for trying to find clean ways to add chaining to langauges like JS, but feel we are working at the wrong level of abstraction. Chaining is a syntax and grammer problem, not a semantic problem. Smalltalk solved this by making chaining part of the syntax. if you write:<p><pre><code> foo
:bar;
:bash something;
:thenBlitz.
</code></pre>
The semi-colons tell the interpreter to chain the method calls to the original receiver. That way you can read the sntax and know chaining is involved without needing to know whether those methods were written to be chained. The return value of a method is its <i>semantics</i>, and should not be chosen to try to implement syntax.<p>Summary: This problem should be solved by the parser, not by the function author.<p>p.s. paging @jashkenas!<p>p.p.s. Did you ever take that test yourself? Yes, my comments apply doubly to libraries like #andand.
Reminds me of node-chainsaw: <a href="https://github.com/substack/node-chainsaw" rel="nofollow">https://github.com/substack/node-chainsaw</a><p>Also, my own node-ContextChain <a href="https://github.com/duncanbeevers/node-ContextChain" rel="nofollow">https://github.com/duncanbeevers/node-ContextChain</a><p>Both of these libraries take the approach of wrapping the underlying object rather than modifying it.
This website (much like all of Lea's work) has loads of really nice details – worth reading through the source code for anyone who works with CSS. Particularly the use of border-image, though there are a number of other nice little things going on here!
I've always thought the chaining methods thing that jQuery popularized was a pristine example of an anti-pattern. It might save a few keystrokes, but I question whether anyone really writes code like this the first time through. I suspect people actually take perfectly fine working code and refactoring it into a chain just to make the code appear more clever, all the while making the code harder to read and debug.