Improve chaining syntax
JulianBirch opened this issue · 180 comments
Since chaining is a pretty common feature of Javascript libraries, how about a dedicated syntax for it?
e.g.
$("p.neat").addClass("ohmy").show("slow");
could be written
$("p.neat").. # Note the "dot dot"
addClass "ohmy"
show "slow"
Alternatively, you could go with something insanely LISPy
->>
$ "p.neat"
addClass "ohmy"
show "slow"
NB, the semantics I'm proposing would be equivalent to
a = $ "p.neat"
b = a.addClass "ohmy"
c = b.show "slow"
I think this is a duplicate of #1251
Yes and no. The problem is the same, but proposed solution is different. 1251 was rejected and closed because the syntax proposed ultimately didn't actually improve matters. I feel the above proposals do, in fact, produce a nicer syntax for "train wreck" expressions. It requires you to use separate lines and indentation, but if you wanted to do it on one line, you could still fall back to the existing syntax. I've realized the ".." syntax can be futher improved to
$ p.neat..
addClass "ohmy"
show "slow"
Which I feel looks a lot more like coffeescript than
$("p.neat").addClass("ohmy").show("slow")
How about just putting the dots there as usual, but instead of this code:
$ "p.neat"
.addClass "ohmy"
.show "slow"
compiling to this JS as it does now:
$("p.neat".addClass("ohmy".show("slow")));
it would compile as expected to this JS:
$("p.neat").addClass("ohmy").show("slow");
This would essentially make the newline character mean something after function calls without parenthesis.
@devongovett cute, but wouldn't that syntax make it harder to correctly parse this valid (and pretty common) construct?
lemmeTellYas 'all about some fruits'
kiwi: 'real itchy-like'
okra: 'all slimy inside'
fig: 'full of little wasps'
@erisdiscord no, I don't think so as the dots before the function names would be required and there aren't any colons after them. It's really the same as if you just removed parenthesis from around the arguments of each function.
Whilst my preference for as little punctuation as possible is marked, I can't see anything unambiguous with Devon's rule.
+1 for @ devongovett's proposal — this might be the behavior I'd expect anyway.
Y'all should take a look at #1407. The proposal there would allow you to write
$ "p.neat"
.addClass "ohmy"
.show "slow"
without making newlines/indentation significant. In my view, it's the most elegant possible solution to this long-standing problem.
A more explicit way perhaps could be
$ "p.neat" > addClass "ohmy" > show "slow"
or even with surrounding spaces
$ "p.neat" . addClass "ohmy" . show "slow"
currently writing all the () parenthesis is a pain.
I don't like the idea of using straight indentations for chaining. Indentations to me means "Sub/Below" but chaining is more like "Next"...
Something like
$ "p.neat"
.addClass "ohmy"
.show "slow"
would make more 'sense' but Jeremy already wrote that off here.
Maybe something like:
$ "p.neat" >
addClass "ohmy"
show "slow"
could work.
I kinda like JulianBirch idea for .. as well...
$ "p.neat" .. addClass "ohmy" .. show "slow"
$ "p.neat" ..
addClass "ohmy"
show "slow"
Just to throw another syntax in the ring, the ellipsis operator could be overloaded to mean "continue with result of last line", as such:
$ "p.neat"
...addClass "ohmy"
...show "slow"
You're not really saving punctuation but it is very simple to write, just as easy to read.
As qrgnote points out, jashkenas doesn't like the leading dots proposal. Satyr does, obviously, since it works in Coco. Personally, I think* that when writing normal javascript, it's more common to be writing ")." or "})." at the start of a line than just ".", which makes me favour changing the behaviour.
I don't think using "greater than" works, because it's impossible to tell what you meant by ">" anymore. Which actually pretty much leaves us with the ".." proposal.
*I remember than when Python introduced their inline if statement, they designed it on the basis of analysing a large code base (their own) to see what was the more common idiom. I did a quick scan of jQuery edge for ^\s+[.] which found only one case in which the "dot on newline implicitly closes a bracket" would not have been the intended behaviour.
For reference, the line was
if (rvalidchars.test(data.replace(rvalidescape, "@")
.replace(rvalidtokens, "]")
.replace(rvalidbraces, ""))) {
It'll be great if it can work inline as well... because going back and adding (&) is annoying.
check = require "validator" ... check
could return
check = require("validator").check
Edit:
Actually in practice entering ... is weird inline... keeps me thinking of "to be continued", maybe > or . (spaces) would be best.
check = require "validator" . check
check = require "validator" > check
Why fix something that is not broken? Introducing new meaning to existing symbols and operators is risky as at some point the JavaScript itself could decide to overload them. And chaining calls is not a common idiom in either CS or JS. It's just something that one popular client-side library happens to use.
Ruby is fine without chained call support. JS and CoffeScript offer you working solutions that require you to be verbose. If you need something else, you can probably roll your own solution without modifying the language, see this Ruby example for an idea of what to add to jQuery's prototype:
Underscore isn't the only popular library that uses method chaining. jQuery uses it as well. The reason I suggested the ".." syntax is because that's the syntax Clojure has for this, so it's useful in Java as well.
@JulianBirch, I agree but the idiom is still not part of the language philosophy per se and reusing operators that are already part of the language comes with the risk of them suddenly gaining a meaning in a future version of JS.
Certainly, and tbh I think this has come down to a "won't change". I do find thrush operators useful, however, and it's a pity CoffeeScript doesn't have one.
$ "p.neat"
.addClass "ohmy"
.show "slow"
this is exactly what I'm looking and expecting for.
parenthesis is really a pain when doing chaining
yes, CoffeeScript does not support chaining.
You can't use CoffeeScript to chain, you have to resort to JavaScript.
CoffeeScript does such a great job of relieving parenthesesitis, that when I have to return to JavaScript awk!!! Especially when I have to "go back" to add parenthesis.
it's not easy to add parentheses backwards
my-module = require './mymod'
# awk! have to go to back and add parentheses
my-module = require('./mymod').method
It seems that not supporting chaining is an oversight of CoffeeScript. Chaining isn't just used by jQuery like the previous example shows, it's pervasive in CommonJS modules loading, and what's more Node, then that? Let alone a lot libraries like Underscore supports "chaining" as well. Like mongodb/mongoskin
posts = require('mongoskin').db('localhost:27017/blog').collections('posts')
jQuery and all the custom libraries built off of jQuery is important to support native imho. Parentheses sucks. I don't want to write JavaScript, I want to write CoffeeScript.
Question, why was "parentheses" made optional on function/method calls in the first place? That same rationale should be why chaining should be supported without parentheses.
chain 'uh'
chain('uh').chain "why does"
chain('uh').chain("why does").chain "my method calls"
chain('uh').chain("why does").chain("my method calls").chain "sometimes requries"
chain('uh').chain("why does").chain("my method calls").chain("sometimes requries").chain "parentheses"
Simple, CoffeeScript doesn't support chaining.
Consider me insane but I find foo = require('bar').baz much shorter and way more readable than:
foo = require 'bar'
.baz
If parentheses are your number one problem in programming then let me congratulate you for having nothing else to worry about :)
yes, CoffeeScript does not support chaining.
Wait, what?
You can't use CoffeeScript to chain, you have to resort to JavaScript.
Huh? This looks like CoffeeScript to me: $('.awesome').css(color: randomAwesomeColor()).appendTo('.gr8-stuff')
While I agree that a syntax that allows us to leave off parentheses would be the ant's pants, the status quo really isn't as bad as you make it sound. We've been using parentheses for years in other languages. C:
(If you're allergic to parentheses, you'll want to be extra careful and avoid exposure to Lisp or S-expressions)
$('#blah')
.bar('foo')
.bar('foo')
.bar( ->
fn()
).bar 'foo'
$ '#blah'
.bar 'foo'
.bar 'foo'
.bar ->
fn()
.bar 'foo'
I think the latter would make my day better :)
Food for thought from @raganwald: http://news.ycombinator.com/item?id=3175028
The substance of my comment onHN:
I would use indentation to discriminate between the cases:
list
.concat(other)
.map((x) -> x * x)
.filter((x) -> x % 2 is 0)
.reverse()
For pipelining, and:
brush
.startPath()
.moveTo(10, 10)
.stroke("red")
.fill("blue")
.ellipse(50, 50)
.endPath()
For what we are calling “chaining.” I use this now as a personal coding style when writing jQuery stuff with JQuery Combinators:
added
.addClass('atari last_liberty_is_' + ids_of_added_liberties[0])
.find('#'+ids_of_added_liberties[0])
.when(doesnt_have_liberties)
.removeClass('playable_'+added_colour)
.addClass('no_liberties');
The first “addClass” and “find” are both sent to “added,” “when” is sent to the result of “find”, “removeClass” and the second “addClass” are both sent to the result of “when.” It feels to me very much like how we indent scope and syntactic blocks like “if” or “unless."
@raganwald 👍 That is precisely how I feel it should be as well, if CoffeeScript is going to have such a syntax. Lately I tend to write my chained method calls on the same indentation level as the object
brush
.startPath()
.moveTo(10, 10)
…
but I think that indenting it your way makes more sense and is ultimately more consistent.
Consider me insane but I find foo = require('bar').baz much shorter and way more readable than:
foo = require 'bar' .baz
yes, but a single line chaining syntax would be nice.
foo = require 'bar' . baz
# or
foo = require 'bar' > baz
foo = require 'bar' .. baz
foo = require 'bar' ... baz
but @patrys point about future-proofing coffee-script is a good point...
we just have to decide on a syntax.
my vote right now goes for .. or both...
brush
..moveTo 10, 10
..stroke "red"
..fill "blue"
..ellipse 50, 50
brush ...
.moveTo 10, 10
.stroke "red"
.fill "blue"
.ellipse 50, 50
FWIW, Smalltalk implemented chaining in its syntax and was indentation agnostic, so you could write
foo
bar;
bash: something;
thenBlitz.
or:
foo bar; bash: something; thenBlitz.
If you want to go that way, I would avoid .. as a potential readability and accidental mistype liability for the same reasons that = and == often trip people up in if statements. JM2C.
Unfortunately, the semantics I would like in an operator conflict with Coffeescript’s goal of compiling to readable JS that corresponds closely to the semantics of the original source. Instead of an operator that means “send and return the receiver,” I would like an operator that means “send to the previous receiver,” which is exactly what the ; in Smalltalk means. So instead of:
foo
..bar()
..bash(something)
.thenBlitz()
I would have suggested:
foo
.bar()
&.bash(something)
&.thenBlitz()
Meaning “send bar to foo, and send bash(something) to foo, and send thenBlitz to foo.” I fear that the compiled code would be confusing, but like the way it reads. It describes to me what the code is doing, not making me think about the implementation of returning the receiver and then sending a message to the result.
Like .., you could still use it on one line:
foo.bar()&.bash(something)&.thenBlitz()
@raganwald +1. This seems like an intuitive, semantic distinction between chaining vs continuation of previous lines.
Moved comments about chaining parentheses omission to #1407.
Just to recap, it looks like we're discussing three problems:
-
Multi-line chaining vs. pipelining syntax (sort of a
with-like construct) using indentation or perhaps a new operator:$('body') .html('<h1>hey</h1>') .find('h1') .addClass('cool') -
Permitting multi-line paren-free chaining syntax:
$ 'body' .html '<h1>hey</h1>' .addClass 'cool' -
A single-line chaining syntax using perhaps a new operator a la
require 'foo' .. baz
@raganwald: Instead of an operator that means “send and return the receiver,” I would like an operator that means “send to the previous receiver,” which is exactly what the
;in Smalltalk means.
A separate proposal. See #1431.
Thanks, @timcameronryan. Let me add that there is a separate open issue for that second problem, #1407.
So to clarify, @raganwald: Are you proposing a chaining syntax where function results are cached as needed so that you could write, for instance,
$('#todos')
.addClass('rad')
.children()
.addClass('tubular')
.parent()
.addClass('dudetastic')
and have it be equivalent to
_ref = $('#todos');
_ref.addClass('rad');
_ref.children().addClass('selected');
_ref.parent().addClass('active');
? Or are you just suggesting a stylistic convention?
If my dreams came true, then:
$('#todos')
.addClass('rad')
.children()
.addClass('tubular')
.parent()
.addClass('dudetastic’)
Would compile to something like:
_ref1 = $('#todos');
_ref1.addClass('rad')
_ref2 = ref1.children();
_ref2.addClass('tubular');
_ref3 = ref1.parent();
_ref3.addClass('dudetastic’);
The obvious optimization is to take advantage of the fact that some of these ’nodes’ are degenerate and do not have more than one child:
_ref = $('#todos');
_ref.addClass('rad’);
_ref.children().addClass('tubular');
_ref.parent().addClass('dudetastic’);
This is exactly what @TrevorBurnham is asking. Presuming we have degenerate node optimization, this code:
list
.concat(other)
.map((x) -> x * x)
.filter((x) -> x % 2 is 0)
.reverse()
Compiles to itself:
list
.concat(other)
.map(function (x) { return x * x; })
.filter(function (x) { return x % 2 === 0; })
.reverse();
Trevor's example:
$('#todos')
.addClass('rad')
.children()
.addClass('tubular')
.parent()
.addClass('dudetastic')
This is both valid CoffeeScript and valid JavaScript. While I see a great deal of merit in the proposal to make whitespace significant in such cases, the fact that a piece of code can be valid in both languages but mean different things is a cause for concern.
Personally, I don't have much of an issue with flat indentation in either of @raganwald's examples. I don't do indentation like that when programming in Clojure, and I don't believe anyone else does either. It's well understood that each line (form) of -> operates on the result of the last one. If the last function happens to return its own parameter, that's fine, but not a cause for a different indentation strategy. Take a look a clj-webdriver for an extended exercise in using -> as a chaining syntax.
To clarify, what I was trying to set out to do at the start was propose a syntax that made chaining APIs easier to use than CoffeeScript, not provide a way of doing chaining-like things on things that didn't already support them.
If you just wanted to simplify the case in which the chain always returned the same object, VB6's with statement would do the job:
with $ 'p.next'
.addClass "ohmy"
.show()
I imagine most JS programmers are pretty allergic to anything containing the word "with", however...
Oh, and if I wanted to extract variables from a require, I'd have written
{bar} = require 'foo'
In the first place. :)
Actually the concept behind with does not work well with standard chained code, while useful for other purposes.
# pseudo code
with $ 'div'
.find 'span'
.addClass 'span-element' # following `with` concept this should be applied to `$ 'div'`should hypothetically yeld to:
var _ref = $('div');
_ref.find('span');
_ref.addClass('span-element');and not:
var _ref = $('div');
_ref=_ref.find('span');
_ref=_ref.addClass('span-element');What about:
with $ 'div'
with @find 'span'
@addClass 'span-element'
Not that it would make the code any shorter than JS.
I like @davidchambers’s observation and agree that we should be concerned that:
a = [1, [2]]
a
.pop()
.pop()
and:
a = [1, [2]]
a
.pop()
.pop()
Are both valid JS with identical semantics. If Coffeescript is to have different semantics, it ought to be a big win for developers.
Tangentially, I find it surprising that Coffeescript is a language with “significant whitespace” but both of the above are valid Coffeescript and both compile to exactly the same code. If they don’t compile to different JS, I would expect Coffeescript to tell me that one of the two is illegal.
One of the benefits of a significant whitespace language is to use whitespace to save on things like braces and end statements. The other is to enforce a single consistent indentation across all code. Allowing both forms discards this second benefit.
I’m just ruminating here, I am not agitating for change. I’m flattered that you folks found my suggestion interesting enough to take the time to consider the ramifications, and I look forward to seeing how chaining might evolve into Coffeescript.
I like the raganwald era syntax.
Just wondering if it might support assignment:
Cuz = extends Bro, ( args... ) ->
...
::doStuff = ( args ) ->
...
.doThings = ->
...
Might go some way towards #1632, at least for class definition...
{bar} = require 'foo'
is the same as
bar = require('foo').bar
@JulianBirch cool didn't realize that, thanks. :)
Does this proposal boil down to this?:
"Any statement starting with a dot implicitly operates on the value from its indentation parent."
If so, I'm -1. In cases where the indentation parent is far away, I think this will cause readability concerns. Also, I think many readers would expect the implicit object to come from the prior line.
I've only skimmed this thread, but it seems like nobody has put forward a concise explanation of what the rule would be. I understand that it's still a work in progress.
@showell one could also argue against the indented if or for syntax using that same argument. It's not up to CoffeeScript to prevent bad programmers writing hard to read code.
@erisdiscord Are you saying that CoffeeScript's design decisions don't impact code readability? Nobody with any sense of nuance would suggest that my arguments apply to if/for. That's just silly.
The code below could have multiple interpretations:
brush
.startPath()
.moveTo(10, 10)
.stroke("red")
.fill("blue")
.ellipse(50, 50)
.endPath()
The endPath() fragment could be acting on "brush", or it could be acting on the value returned from "ellipse". Obviously, only one interpretation would be valid under this proposal, but I think CS newcomers could reasonably expect either interpretation.
I'm all in favor of constructs that lead to terseness, but not if they introduce ambiguity.
@showell I'm not saying CoffeeScript's design decisions don't impact code readability, but I think your argument is weak unless I'm misunderstanding it.
Vagueness and contrivance aside, how is either of these examples any harder to read than the other? In both cases, we end up with statements far from their indentation parent and readability is affected about the same IMO.
$ 'article'
.applySomeStyle()
.find 'h1'
.makeNeatHeading()
.addToTOC()
.find 'p'
.extractPullQuotes()
if entity?
entity.updatePosition()
unless 0 <= entity.x < width
entity.x += width
doSomething()
unless 0 <= entity.y < height
entity.y += height
doSomething()
I think my sense of nuance is in working order, thanks.
@showell .endPath() could apply to the return value of ellipse, sure, but under this proposal it wouldn't. There's no ambiguity because the meaning is well defined: a statement beginning with a dot applies to the result of its indentation parent. I would expect someone to learn the basics of the language if they intend to maintain code written in it.
This proposal is consistent with implicit object literals, BTW, where there's no confusion about what object andSoOn belongs to:
parentObject:
childA:
someGrandChild
anotherGrandChild
childB:
yetAnotherGrandChild
andSoOn
But this argument isn't the same as arguing that the distance from its indentation parent would affect readability, which is the point that I was addressing.
@erisdiscord Yep, I'm making two different arguments. My first argument is that .endPath applies to an object that is five lines above the statement, which means the reader has to keep more context in his head to understand what should be dead-simple code. My second argument is that the rules of the language wouldn't be obvious to a newcomer.
@showell I think we have a fundamental disagreement on the issue, so I'm gonna let this be my last comment on the matter. I don't think you're wrong per se, but I don't think you're right either. ;D
It's a potentially very useful bit of syntax sugar that definitely has potential for abuse, but I feel like the potential for convenience outweighs the potential for bad code.
Sorry for repeatedly editing my comments, meanwhile; I just keep noticing things that I left out or could have phrased better. I think I'm happy with what I've written now. C:
@erisdiscord asks how these snippets compare in terms of readability:
$ 'article'
.applySomeStyle()
.find 'h1'
.makeNeatHeading()
.addToTOC()
.find 'p'
.extractPullQuotes()
if entity?
entity.updatePosition()
unless 0 <= entity.x < width
entity.x += width
doSomething()
unless 0 <= entity.y < height
entity.y += height
doSomething()
Vagueness and contrivance aside, the second example is more readable, because every individual statement in the second example explicitly refers to all the objects it's invoking/referencing (e.g. "entity", "width", "height", "doSomething"). I'm not oblivious to the fact that you still need to read up in the code to know whether the statement even executes, but that doesn't undermine my argument.
@erisdiscord I think your examples will help clarify the debate. Obviously, it's ultimately a judgment call, as I can't see how there's any clear "right" or "wrong" answer. No prob on the edits, I think my answers still make sense in context.
@showell has made some very convincing arguments. I agree with everything he's said. -1.
I agree that the drawbacks are real, but I also feel that they're outweighed by the benefits. I love the way that this proposal reduces both repetition and, in many cases, temporary variable declarations. Any surprising behaviors that result should be easy to diagnose by compiling to JS.
"Any statement starting with a dot implicitly operates on the value from its indentation parent.”
Yes. This code:
$ 'article'
.applySomeStyle()
.find 'h1'
.makeNeatHeading()
.addToTOC()
.find 'p'
.extractPullQuotes()
Is already legal CS, we are simply discussing what it means, not whether it should be legal. As for it being “far from its indentation parent,” that’s the beauty of indentation. It’s ‘far' in chars and lines, but visually, it’s easy to see.
The structure of the indentation exactly maps to the structure of the expression, and the eye easily finds the indentation parent at a glance. That’s exactly why people indent outlines.
Yes, I suppose I would like to add one last thing on the subject of indentation: if you use tabs and your editor has a setting that shows them, it's incredibly easy to trace back to the parent.
It might even be possible to alter the CoffeeScript mode for TextMate or any number of other editors to stripe your indentation, whether spaces or tabs, provided the syntax highlighter can know what constitutes a single level of indentation.
I like the ragenwald proposal for this. I think the strongest argument is the comment he made on hacker news but didn't paste here:
http://news.ycombinator.com/item?id=3175028
My suggestion is that "chaining" method calls is a syntax issue and not a function issue, and that writing functions to return a certain thing just to cater to how you like to write programs is hacking around a missing language feature.
pop() is a great example. Why shouldn't pop return the receiver? The first example makes sense, you ought to be able to chain calls to pop(). Then again, why shouldn't pop() return what it pops? You ought to be able to pop something and use it, just like the second example.
Baking chaining into what functions return forces the function author to choose On behalf of the function user. I do not blame people for doing this in a language lacking thenproper syntax, but given how much people do this, it seems worth considering for people writing new langauges or new syntaxes for existing languages.
I like that his proposal allows the caller to decide if they want the object (cascade) or the returned value from the function (chain) for the next line of code. This frees the function to return a value instead of the object.
+1 @raganwald's proposal. I'm not perturbed by semantic difference from javascript. CoffeeScript is not javascript anyway.
@raganwald's++
+1 @raganwald's proposal as well. It's true that it's different from the current indentation behavior but then again, a lot of things in CoffeeScript are different than JavaScript. I rarely chain methods together but when I do, the methods in the chain already return the object in question (since otherwise chaining would be impossible), and so this:
foo
.bar()
.baz()
and this:
foo
.bar()
.baz()
would behave exactly the same and not be surprising to fellow developers. So the only case in which this new whitespace feature would be used, probably, would be when chaining jQuery selector methods, and there I can definitely see the use case for it.
FWIW the idea of an implicit object receivers being linked to the parent of the block has precedence in Visual Basic:
With testObject
.Height = 100
.Text = "Hello, World"
.ForeColor = System.Drawing.Color.Green
.Font = New System.Drawing.Font(.Font, _
System.Drawing.FontStyle.Bold)
End With
My main problem with VB isn't the clumsy With/End With. I wouldn't even like VB if it were indentation-based:
testObject
.Height = 100
.Text = "Hello, World"
.ForeColor = System.Drawing.Color.Green
.Font = New System.Drawing.Font(.Font, _
System.Drawing.FontStyle.Bold)
I just don't like implicit receivers. If you need to pop three items off an array, just keep it simple:
array.pop()
array.pop()
array.pop()
The syntactic repetition mirrors the semantic repetition.
It seems like there are a few use cases for the fluent style:
- You are setting a bunch of attributes on a DOM element. IMHO that should be the job of your stylesheets. Set the class within CS, then specify all the particulars of that style within CSS.
- You are repeating the same operation on object multiple times. IMHO that is the job of a loop.
- You are setting a bunch of properties on an object. IMHO that is either a symptom of a heavy language like Java or overly coarse objects.
So with @raganwald's proposal, https://github.com/jashkenas/coffee-script/blob/1.1.3/examples/underscore.coffee#L604 would have to be
str.replace(/\r/g, '\\r')
.replace(/\n/g, '\\n')
.replace(/\t/g, '\\t')?
Or this would work
str.
replace(/\r/g, '\\r').
replace(/\n/g, '\\n').
replace(/\t/g, '\\t')Trailing dots behaviour would be unchanged by the proposal.
@raganwald's +1
who's confused? Raise their hand...
More updates from @dherman: http://blog.mozilla.com/dherman/2011/12/01/now-thats-a-nice-stache/
@alessioalex +1
oh “monocle-mustache” will kill chaining? Boo... I thought we wanted to improve chaining... not kill it ....
:/ seems kinda crazy, unless CoffeeScript have a different syntax for chaining... but that might be confusing...
@quangv @alessioalex it's not gonna kill chaining. As the proposal stands, you'll still be able to chain methods on a single line or by using indentation.
anObject.foo().bar().baz()
anObject
.foo()
.bar()
.baz()
It's also very likely that ending a line with the dot operator will still continue that line as before rather than triggering the new cascading syntax.
anObject.
foo().
bar().
baz()
Mind, I don't recommend writing it this way if this proposal is adopted because it could be confusing, but eh. C:
Of course, if the methods foo, bar and baz are just returning this anyway, as is typically the case with jQuery, then you can continue to write it the same way as long as you're mindful of indentation.
I don't want to see code like this:
v = obj
.foo().
bar.
baz()
.qux
Ever. I would lose my mind. It should be exactly equivalent to v = obj.foo().bar.baz().qux. Assuming I understand this proposal fully, I would have to figure out that the programmer meant obj.foo().bar.baz(); v = obj.qux, which would be better if it was just written like that in the first place.
edit: typo
Since nobody else has asked, an open question is, “With @raganwald’s Significant Whitespace suggestion, what does the following return?”
(...)
.bar()
.blitz()
Is it equivalent to:
(function () {
var _ref1 = (...);
_ref1.foo();
return _ref1.bar();
})()
Or does it have Kestrel/_.tap semantics:
(function () {
var _ref1 = (...);
_ref1.foo();
_ref1.bar();
return _ref1;
})()
The second interpretation is nice for initialization code, very similar to object initializer blocks in ActiveRecord:
myNewThingummy = new Thingummy(...)
.doSomeSetup()
.someProperty = someValue
.anotherProperty = anotherValue
.finishSettingUp()
Like it? Hate it?
@raganwald: As you could probably tell from my above comment, I was assuming the first interpretation. And I would probably prefer that, though it's irrelevant since I still haven't bought into the syntax yet.
@michaelficarra, I would be bewildered, perplexed, and discombobulated by code such as:
v = obj
.foo().
bar.
baz()
.qux
However, now that you mention it, if I want to write:
v = obj
.foo()
.bar
.baz()
.qux
And mean v =obj.foo().bar.baz.qux(), then the really significant indentation thing should not have Kestrel/_.tap semantics, otherwise it would resolve to obj.
@raganwald, that is a good point. I don't know what people would want... probably more often that not people would not want tap semantics, but I think there is a case for it. It sounds your proposal is something that would need to be tested out for a while to see if it really works in the wild.
anyway to make
x 'cat' .dog
=
x('cat').dog
?
just wanted to make sure...
update: @michaelficarra thanks.
I like @raganwald's proposal, I really do. The idea that method invocations respect indentation the same way that hashtables do is rather elegant. (My personal answer to @raganwald's question is that the latter behaviour is probably the sensible thing to do.)
However, more generally, I'd regard the motivation behind the proposal as being twofold (YMMV)
- to enable a more point-free style than is currently possible
- to reduce the number of times parens are required
I'm rather concerned that the underscore list comprehension example of @raganwald's looks rather inelegant. Maybe we need a way of specifying that we should be using the value of the previous line rather than the previous indentation.
To rewrite one of @raganald's examples:
list
.concat(other)
.map((x) -> x * x)
.filter((x) -> x % 2 is 0)
.reverse()
could become
list
|concat other
|map (x) -> x * x
|filter (x) -> x % 2 is 0
|reverse()
(Pipe was chosen to indicate "pipelining", but the exact syntax doesn't matter that much to me.)
Super small idea on @JulianBirch pipe proposal: using : instead of pipes, it resembles the dot notation but it's vertically continued.
list
:sort comparable
:reverse()
:push 'some', 'other', 'element'
The more I think about it, the more I like it.
I think the @raganwald proposal is cleaner than any of the alternatives (even mustache oriented). It even allows accessors like :: to modify prototype properties.
It seems a little unclear when used with functions:
Thing = ->
@createdAt = new Date()
::toString -> "I am a thing."
But maybe we can write instead:
Thing = ->
@createdAt = new Date()
::toString -> "I am a thing."
I.e. no indentation necessary for cascading access at root level.
A suggestion for handling return value:
Suppose the default is tap semantics, in this case root:
root
.foo
.bar
.baz
To return an intermediate value, add return as per cascade, in this case, the object returned by foo:
root
.foo
.bar
.baz
return
I realise this is a little loose, just a suggestion.
Anyway, really like this proposal, hope it goes through more-or-less as-is.
@raganwald +1, I like it.
@timcameronryan
Just to recap, it looks like we're discussing three problems:
Multi-line chaining vs. pipelining syntax (sort of a
with-like construct) using indentation or perhaps a new operator:$('body') .html('<h1>hey</h1>') .find('h1') .addClass('cool')Permitting multi-line paren-free chaining syntax:
$ 'body' .html '<h1>hey</h1>' .addClass 'cool'A single-line chaining syntax using perhaps a new operator a la
require 'foo' .. baz
These 3 still relevant?
It seems a little unclear when used with functions:
Thing = ->
@createdAt = new Date()
::toString -> "I am a thing.”
I agree this is a little unclear. That being said, with my proposal it is not ambiguous. If we adopt this reasoning:
foo
.bar # <- Never refers to “foo,” it either refers to a parent or it’s a syntax error
Then we know that the following is unambiguous:
foo = ->
gronk
.bar
It is always:
foo = ( () -> gronk ).bar
I agree it is unsightly, I would probably find another way to express my program. A similar thing happens with
foo = bar.map (x) ->
gronk(x * x)
.reduce (a, b) ->
a + grundle(b)
Which I would rewrite as:
foo = bar
.map (x) -> gronk(x * x)
.reduce (a, b) -> a + grundle(b)
I suspect that chaining multi-line functions looks better with the current lack of significant whitespace, but chaining and cascading one-line method invocations looks better with my proposal.
Using a “pipe” or | as an infix to achieve Thrush semantics is a great idea, and I think it has been seen in the wild in other languages that permit operator overriding. I also seem to remember the possibility that it has been used for function composition, as in:
foo = (x) ->
# ...
bar = (x) ->
# ...
fubar = foo | bar
Maybe piping functions deserves a separate proposal/discussion for Coffeescript? If so, please ping me so I can participate in the discussion.
p.s. I would have sent this as a message, but since you haven’t included an email address in your profile, Github won’t let random drive-by people unilaterally stuff your inbox with their drivel...
(| is used in kaffeine as an alternative function call style, similar to bash's pipe, where arguments precede the function)
Wouldn't | conflict with the bitwise OR operator?
I also think this discussion is getting way too far away from JavaScript. CoffeeScript has always been "just JavaScript" expressed slightly differently, and usually things that are too far away from JS are not excepted. I am starting to think that all of these weird new syntaxes are getting a little too far fetched. I personally think CoffeeScript should keep the "just JavaScript" feeling, and support chaining the same way as in my proposal above, which would basically change the output of this CoffeeScript:
$ "p.neat"
.addClass "ohmy"
.show "slow"from this:
$("p.neat".addClass("ohmy".show("slow")));to this:
$("p.neat").addClass("ohmy").show("slow");and be equivalent to this CoffeeScript with parentheses:
$("p.neat")
.addClass("ohmy")
.show("slow")Anything more than that I think is going too far away from the "just JS" feel that the language has always had.
Which I would rewrite as:
foo = bar .map (x) -> gronk(x * x) .reduce (a, b) -> a + grundle(b)
Rewrite in current CoffeeScript you mean? That .reduce would be sent to bar with your proposal, wasting .map.
i.e. I think CoffeeScript should retain the semantics of JS but not the syntax. @raganwald’s proposal goes too far away from the semantics of JS in my opinion. I also don't like the look of all those indentations just to chain stuff together, but perhaps that's just me.
I think CoffeeScript should retain the semantics of JS but not the syntax. @raganwald’s proposal goes too far away from the semantics of JS in my opinion
Two points. First, I agree that it introduces new semantics. However... Doesn’t that also apply to any and all discussion about introducing cascading syntax? In other words, if significant whitespace is a bad idea because it introduces new semantics to JS, aren’t we also against introducing .. and ->> and everything else suggested here?’’
Second, it’s obvious that people want this, given how much work is being done to back them into JS through fluent interfaces. If Coffeescript doesn’t introduce cascading message syntax, people will find another way to cascade messages. So, I suggest we accept that cascades are a part of Javascript, and all we are discussing is how Coffeescript programs should represent them.
And of course, I’m ok if the answer is, “We feel that the best way for Coffeescript programs to represent cascades is the way Javascript represents them, by library authors greenspunning the feature into the semantics of their functions."
@devongovett what do you mean the 'the semantics of JS' ?
raganwald's proposal, what's the difference between these ?
root
.foo
root
.foo
root()
.foo
root
.foo
# => root.fooroot
.foo
# => ERRORroot()
.foo
# => ERROR@raganwald yes I am against all of the other cascading proposals as well. When I look at a piece of code I should be able to understand what it does immediately. These proposals break what I assume should happen when I read the code.
Chaining already works fine in JS. Libraries like jQuery have shown that. Chaining already works in CoffeeScript the same way as it does in JS as well, if you use parentheses around your function calls. I think all we need is to extend that such that one could chain non-parenthesised function calls as well as in my example, or do nothing at all. I'm not really sure there is a problem beyond that. In fact, I'd be fine with doing nothing and leaving it as it currently is -- if you want to use chaining, you have to use parentheses to be clear. All of this new syntax (some of it breaking the beauty of CoffeeScript) and breaking the JS-like semantics that the language has is not something I think CoffeeScript should do.
if you want to use chaining, you have to use parentheses to be clear
The more pertinent point is that if you want to use chaining, the methods you're invoking must return an appropriate value.
Sure, jQuery does this and it works beautifully. But @raganwald's argument is that JavaScript libraries shouldn't have to be written in this way in order to be used in this way.
Yup and I disagree. If I'm a library author, I want control over how my API will be used. It really isn't that hard to add return this to the functions you want to be chainable. Really it isn't.
It really isn't that hard to add
return thisto the functions you want to be chainable. Really it isn't.
No, it isn’t that hard except that CoffeeScript and JavaScript only allow functions to return one thing, so when you decide that .pop() should be cascadable, you are also deciding that it can’t be pipelined as in undoStack.pop().undoIt(). Likewise, on the surface it’s easy to say that current code does what we expect by sending each method to the return value of the whitespace-agnostic previous method invocation, but that hides the deeper reality that some methods return their receiver and some don’t, forcing the reader to look up what the method does to understand what the code does.
It’s easy to write return this, harder to read it when you are trying to understand a block of code at a glance. It doesn’t feel hard to us as API authors because we know our own libraries by heart. But we should have some empathy for the people who read the code our users write. A syntax for cascading messages (mine or any other) makes it easier for code readers and writers.
I suggest it’s easier for API authors too: In choosing to return this, we are mixing two separate concerns: What our functions do in a domain-specifc way, and how they should be used in a syntactic way. I am loathe to invoke clichés as if they are immutable tenets of wisdom, but I urge you to consider the possibility that this is a "separation of concerns” issue and that the answer is—as usual—that separating concerns is desirable.
(JM2C, I like CoffeeScript and I’m sure it will continue to be a fine language no matter how things turn out with respect to this discussion)
OK, I disagree. pop() should do what the API author intended and nothing else. It might be a little nicer to be able to chain those calls, but that isn't how the underlying code works, which is misleading. undoStack.pop().undoIt() looks like it is calling undoIt() on the result of the pop() call, which it sounds like you are saying it wouldn't be. That is too much magic for my taste and it changes the semantics of JS too much.
First, we probably agree on a great deal. But to clarify, I agree with you! When I write:
undoStack.pop().undoIt()I am absolutely saying “pop the top command object off the undo stack and send the undoIt message to it." Same as if I write:
undoStack
.pop()
.undoIt()But I also want to sometimes write:
dealCard = (shoe) ->
shoe
.pop()
.pop()
.pop() # burn three cards
.pop() # and return the fourth
I think I understand your feeling that this second (contrived) possibility is not worth what you feel are the drawbacks.
- Having to indent every line just to simulate chaining as it is now is not very pretty.
- There should not be a difference between
shoe.pop().pop().pop().pop()and
shoe
.pop()
.pop()
.pop()
.pop()I should be able to format my code however I like and have it function the same way.
My problem with this proposal is that there's already a dead simple way in CS to apply operations to the same variable over and over again:
dealCard = (shoe) ->
shoe.pop()
shoe.pop()
shoe.pop() # burn three cards
shoe.pop() # and return the fourth
I'm all for the DRY principle, but I would use DRY to drive out deeper abstractions, e.g. popMany.
I know the "shoe" example is contrived; a slightly more real-world example might be useful for this whole discussion, something that goes beyond simple styling of widgets, which is already easy in JS/CS.
You make your point in Earnest. The simple styling of widgets examples above are interesting because they reflect a problem where the data being manipulated is already in a tree-like form, or the algorithm being applied is already in a tree-like form.
Many of the Smalltalk cascading examples I’ve seen use nested cascading when working with nested objects, such as when initializing something complex. I agree that for simple cases, a local variable is often fine. It does sometimes come down to whether you like a point-free style or not.
I should be able to format my code however I like and have it function the same way.
if someCondition
doOneThing() else
doAnother()
Whitespace is already significant in CoffeeScript. I don't see why it should be any different with other parts of the language. The cascade thing isn't without precedent. Consider Smaltalk, IIRC the origin of the message cascade.
dealCard := [ :shoe |
shoe pop;
pop;
pop;
pop.
]
Bringing it up again since it hasn't been aswered: how would one write this so that reduce is chained to map's return value?
foo = bar
.map (x) ->
gronk(x * x)
.reduce (a, b) ->
a + grundle(b)
@erisdiscord but only optionally... I can write it on a single line if I want. if someCondition then doOneThing() else doAnother() This proposal would change the meaning of chaining on a single line vs on multiple lines which is confusing. I realize it has been done before in other languages, but that does not mean it is a good fit for CoffeeScript.