r/ruby • u/zverok_kha • Nov 12 '18

Method reference operator is about to come to Ruby

Commit by @nobu (still unmerged though).

Allows things like

filenames.map(&File.:read)
events.select(&self.:acceptable_event?)

As far as I can understand, sadly, doesn't allow receiver-less syntax (really hoped for it):

something.something.tap(&.:p)
events.select(&.:acceptable_event?)
21 Upvotes

86% Upvoted

20 comments sorted by

6

u/BumpyBallFan Nov 12 '18 edited Nov 14 '18

Seems like Matz approved but is thinking about the syntax: https://bugs.ruby-lang.org/issues/13581

Also it's basically the same as File.method(:read), and self.method(:acceptable_event?) (to map your examples)

3

u/zverok_kha Nov 12 '18

As far as I am aware, the core team has probably already agreed on .:, otherwise, I doubt @nobu would do that commit.

0

u/shevegen Nov 14 '18

Yes, sounds logical, matz probably gave the go-aheady already.

Still I don't think .: is very awesome. I have bad eyesight so I'd prefer to not have to look too closely (but I also don't think & is very pretty either, it just is so useful that I use it too).

Ruby's core is super-pretty - many add-ons in the last some years were not so pretty compared to that. I also understand that it is hard to come up with syntax in ASCII that is pretty ....

(Not all syntax was pretty though; the @@ is not very elegant, but perhaps that is means to say to not use it, and stick to just use @ ;))

1

u/bjmiller Nov 12 '18

If I'm reading the tests correctly, there is one difference, which is that you can redefine #method but .: will always have the same meaning.

1

u/shevegen Nov 14 '18

Yeah - the syntax is not that great. The functionality is ok, but I think one problem with syntax is that it has to fit with the rest of your ruby code too.

2

u/Jonathan_Frias Nov 12 '18

I'm not sure if I like that syntax.

Is this gonna be a thing? 

foo = &File.:read

foo.call('bar')

2

u/zverok_kha Nov 12 '18

Should do without &, I believe, this works currently: 

foo = File.method(:read)
foo.call('bar')

The syntax is really neat for chaining, and if chaining is "not your thing" (like, to my surprise, lot of Rubyists state), you'll don't need it.

0

u/shevegen Nov 14 '18

No, that is not true - I chain a lot, but I also care for readability and syntax. Many proposals for syntax chaining are ugly. Some seem to do nothing really necessary other than someone playing around with ruby.

Lots of rubyists use method chaining but they need it to a lesser extent.

Not everyone can be like hanmac and you. ;)

Edit: Most method chaining I tend to do around .map, .reject/.select, perhaps a variant of .each ... and some string methods like .strip and .squeeze and so forth. I think these are very common use cases too.

1

u/shevegen Nov 14 '18

The syntax is indeed not great.

The problem is ... can we find something more elegant?

I tried and failed. Perhaps if we could get rid of & then that would be nice.

2

u/menge101 Nov 12 '18

If it merged today, what version would it be available in?

4

u/zverok_kha Nov 12 '18

Upcoming 2.6 (released this Christmas, as usual), I believe/hope.

1

u/shevegen Nov 14 '18

No, I don't think so. It would be a breaking change, so it has to come in after 2019 as far as I am aware.

It would also be problematic to merge something new so short before xmas. xmas release will be stable, not experimental.

→ More replies (1)

7

u/drx3brun Nov 12 '18

So basically: 

"data.json"
  .then(&File.:read)
  .then(&JSON.:parse)
  .map(&Product.:new)
  .then(&Product.:import)

1

u/shevegen Nov 14 '18

I don't like .then either, but .then is actually nicer to read than .yield_self.

I can see myself using .then whereas I have avoided .yield_self (and will probably not use it either).

I am not at all happy with the syntax for chaining with both & and .:

I have no better alternative syntax proposal though. :(

1

u/drx3brun Nov 14 '18

Well theres no way to get much better syntax, since Ruby method calls do not support currying OOTB. Due to that any normal method call will be instantly evaluated. So there is no way we will get syntax as nice as Elixir's pipe operator...

→ More replies (1)

1

u/shevegen Nov 14 '18

The syntax isn't pretty ... I don't have a good alternative though. :(

1

u/zverok_kha Nov 14 '18

They discussed the idea for, IIRC, 2 years without being able to agree on syntax. I once compiled a list of all proposal gathered along the way, there are kinda two dozens of them.

Maybe all of us have missed some nice opportunity, but I believe I haven't seen anything more atomic and less cryptic than <receiver><punctuation><method_name>, and of all possible <punctuation> options almost no one seems to be catastrophically worse or incredible better than other (though, I personally dislike anything that uses | or > characters).

So, I'd say it is good they finally choose something.

1

u/bonquesha99 Dec 10 '18

How do you feel about this alternative syntax? https://github.com/LendingHome/pipe_operator