Issue #14594 has been updated by sawa (Tsuyoshi Sawada).


`map` is one of the worst names for this feature in my opinion. Generalizaing from your proposal to use `map` for this feature, we expect:

```ruby
[1].map{|e| e * 2} #=> [1, 1]
```

but that is not what we currently have, nor do you seem to want that. Instead, we have, and you seem to want to handle as an exceptional case, the following:

```ruby
[1].map{|e| e * 2} #=> [2]
```

That is confusing. Why do you want to make something that has worked without problems to this day to become an expection?

----------------------------------------
Feature #14594: Rethink yield_self's name
https://bugs.ruby-lang.org/issues/14594#change-71203

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
*I feel really uncomfortable raising the question again, but...*

In several months since 2.5 release I've written a lot of code with `yield_self` (using `backports` gem with earlier versions of Ruby when necessary), and explained it several times to students, and colleagues (and in this [blog post](https://zverok.github.io/blog/2018-01-24-yield_self.html) which have gained pretty decent attention). 

I should say that I am still assured the name chosen is really not optimal. Reasons:

* it is just too long for such a basic operation;
* it does not say "what it does", but rather "how it is implemented"; it is like having `each_returning_block_result` instead of `map`;
* `self` is really misguiding and obscure in situations like this:

```ruby
class MyClass
  def some_method
    @path.yield_self(&File.method(:read)).yield_self(&Parser.method(:new)) ...
  end
end
```
Intuitively, word "self" inside instance method is read like it somehow related to current context's `self` (e.g. instance of `MyClass`), which it is absolutely not. In other words, "self" in caller's context has nothing to do with "self" implied by method's name.

After reconsidering a lot of options, **my current proposal is: `#then`**.

Reasons:

* despite being a keyword, `something.then(something)` is not a conflicting Ruby syntax, and allowed by current Ruby;
* it is short!
* it shows intention pretty well, and reads natural, in both cases: when receives block and when returns Enumerator:

```ruby
File.read(filename).then(&JSON.method(:parse))
rand(10).then.detect(&:odd?)
```

In many languages, `.then` or `.and_then` is useful construct, meaning the same (calculate next value from the result of the previous operation), just in a narrower context of futures/promises. I believe that even when/if Ruby will have those as a language feature, that syntax will play well:

```ruby
value.then(&:computation) # => value
promise.then(&:computation) # => promise
```

PS: For historical reasons, [here](https://bugs.ruby-lang.org/issues/12760#note-5) is huge list of previous proposals I've gathered for this method name.



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