Issue #12760 has been updated by Robert A. Heiler.


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

You just have to look at various rubygems that have a very strange name.

Animal names for instance - a webserver called puma? unicorn as a  HTTP server
for Rack applications?

I can give you another example too, look at some years ago the "File.exist?" 
versus "File.exists?" when both was made available as alias after some people
spoke to matz. I personally don't care much either way since I understand
both points. In "correct" pseudo-english grammar, we can say "does this
file exist?" and "file exists?", but I remember an explanation by apeiros
on IRC once that this would not be the right question asked according to
matz. The question would instead be "object, do you exist?" or "object,
do you contain xyz?". It may be a subtle and minor difference but it sort
of also taps into the philosophy of ruby.

People need or should be vaguely comfortable with syntax. Take the lambda
stabby operator, I can not overcome my mental obstacle to use it - it just
does not "feel right" in my own code. Lots of other people make use of it,
that is fine by me.

Back to the topic of .itself, while I have no strong objection, I struggle
with other method names such as .tap - whenever I read .tap, I actually
think of a certain card game where you have to tap cards. :)

.inject is another odd one, I think of a big nasty syringe (actually my
brain associates it more as name like "sum of", because that is what I
use .inject most regularly like "array.inject(0){|sum,x| sum + x }"
although I suppose there may be another way these days to get the sum
of all integer/float products of an array).

In conclusion, I think you have to expect a certain resistance in particular
for syntax. Best thing is to try to convince matz. And if it won't 
work within ruby 2.x and neither towards the path towards ruby 3.x
and beyond, perhaps it works for ruby 4.x :)

(Actually, perhaps the DSL aspect of ruby could be extended one day
to allow sub-languages of ruby a bit like lisp dialects... but let's
not get too crazy here.)

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

* 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:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>