Improve chaining syntax

[JulianBirch]

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"

[michaelficarra]

I think this is a duplicate of #1251

[JulianBirch]

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")

[satyr]

Also see #1407.

[devongovett]

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.

[erisdev]

@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'

[devongovett]

@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.

[JulianBirch]

Whilst my preference for as little punctuation as possible is marked, I can't see anything unambiguous with Devon's rule.

[arbales]

+1 for @ devongovett's proposal — this might be the behavior I'd expect anyway.

[TrevorBurnham]

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.

[qrgnote]

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"

[tcr]

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.

[JulianBirch]

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, ""))) {

[qrgnote]

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

[patrys]

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:

http://stackoverflow.com/questions/4099409/ruby-how-to-chain-multiple-method-calls-together-with-send/4099562#4099562

[JulianBirch]

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.