[ruby-core:77300] [Ruby trunk Feature#12760] Optional block argument for `itself`

Issue #12760 has been updated by Victor Shepelev.


>> But, to be completely honest, I'm fascinated by how this simple, easy to
implement and useful functionality have drowned for ages in "better-name-ever"
discussions.

> This is not surprising at all because naming things is one of the hardest
things to get "right".

I can understand your point, but sometimes struggle for excellence should just stop to do the real work.

Concept of `.yield_self` (or whatever we name it) method seems like a huge game-changer to me in a challenge of cleaner and idiomatic code. Yes, it's like Elixir's `|>` operator, but it could be introduced in no effort at all.

Does nobody can see it? 
I don't think so, considering how often the question is raised. Four 4 years now (and it is only proposals that are found in tracker)!

OK, let's summarize EVERYTHING that was proposed (and doubted) so far:

* #6721: 
  * `#yield_self`, 
  * `#yield_to`, 
  * `#submit_to`, 
  * `#surrender`, 
  * `#capitulate`, 
  * `#apply`, 
  * `#ergo` (implemented in Ruby Facets exactly like `#itself` proposed here);
  * `#^` (like `four = 2 ^ { |x| x*x }`)
  * `#self` (again, like `#itself` -- yield-or-return-self)
  * `#cast` (more complicated behavior, like `3.cast(2, :+) => 5`)
  * `#toss`
  * `#tap!`
* #7388 (Matz had explicitly stated he is against all of the options)
  * `#embed`
  * `#infix`
  * `#ergo` again
* #6684 (proposal & discussion is partially in Japanese)
  * `#do`
* #11717
  * `#trap` (was my idea, I've liked it to be close to `#tap` yet was pointed to confusion with `Signal#trap`)
* #10095
  * `#as`
  * `#chain`
  * `#self_by`
  * `#revapply`
  * `#block_self`
  * `#itself` (and big discussion why it is **not** appropriate -- don't really persuadive for me, but you can know batter)
  * `#yield`
  * block form of `#send` (like `(2 + 3).send{ |x| x + 2 }`)
  * new method/operator `~>`
  * Using just `|` operator
  * `#continue`

My favourite is, obviously, `itself`, "reading" reasoning could be found above:

> it is not 100% good English, but readable: `itself(&JSON.method(:parse)) = "parse itself with json"`;

But, to be honest, it is not the point. Point is **we need it**, whatever it is called. And except for "new operator" approach, and versions that will confuse parser (`self`, `yield` and `do`), it is really easy to implement after the name was selected.

Please-please-please, could somebody add this topic to next developer's meeting agenda?..

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60537

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>