From: shevegen@... Date: 2018-03-09T13:50:30+00:00 Subject: [ruby-core:86068] [Ruby trunk Feature#14594] Rethink yield_self's name Issue #14594 has been updated by shevegen (Robert A. Heiler). I agree. Though I have to admit that I never used yield_self so far. I can not even say what it does, either. :) I like yield and self. I don't like the name yield_self. > After reconsidering a lot of options, my current > proposal is: #then. I dislike that as well. I also do not think that "then" makes a lot of sense. For example: File.read(filename).then(&JSON.method(:parse)) This is regular method chaining. But it sounds like you are using a conditional there. "then" is already a keyword in ruby isn't it? https://docs.ruby-lang.org/en/2.5.0/keywords_rdoc.html > 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. Realistically ruby should strive for intrinsic consistency first, not for what features or anti-features other languages may or may not have. > I believe that even when/if Ruby will have those as a > language feature, that syntax will play well: value.then(&:computation) # => value promise.then(&:computation) # => promise I don't think it reads nicely really. yield_self is not a good name but your proposal is also not good, in my opinion. But it's just a personal opinion, feel free to ignore it. At the end of the day you only have to convince matz. :) The name yield_self is however had indeed not a good name. Finding good names is quite difficult. Single words are also almost always better than combined names, even though one is a bit limited with single words alone. There are exceptions though. For example **.each_with_index** or **.each_index** are good names, IMO. ---------------------------------------- Feature #14594: Rethink yield_self's name https://bugs.ruby-lang.org/issues/14594#change-70932 * 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: