From: sowieso@... Date: 2018-04-18T04:03:25+00:00 Subject: [ruby-core:86569] [Ruby trunk Feature#14594] Rethink yield_self's name Issue #14594 has been updated by sowieso (So Wieso). I just like to stress that having an easy and short name is more important than having a name that correctly describes the behaviour. *tap* is also a horrible name that every ruby newbie has to look up first, still it is loved in the community. And that's especially due to the fact that it is short and feels lightweight. As for `yield_self`, no discussion is needed whether this method is needed, but the naming is indeed the difficult part. So I support this discussion (as annoying as it is, how many years is it now?). Let's find a better name (probably an alias)! I would go with (in this order): * **tip** (the closest relative to tap, absolutely short, *tip over* suggests some movement/transfer, probably never used anywhere, tip-tap sounds like a cat walking, downside: not very descriptive at all) * and (like then, even shorter, focus on continuing, probably completely unused, downside: people might think of boolean comparisons, not very descriptive) * then (short, downside: people might think of promises, not very descriptive) * pass (short and somewhat descriptive, might be in use already somewhere) * pipe (short and more descriptive, but used in other contexts (threads, shell)) Some other ideas: * hand (as in hand over, short, probably never used elsewhere, descriptive? (with some imagination)) * chain (probably in use too often) * use (use_here) * pass_me (somewhat longer, pretty clear, reads much nicer than yield_self, but I don't like the *me* either) * yield (already in use, so a no-go, without the self it's short, similar to pass, but too confusing I guess) * relay (probably in use too often) I don't like `tap!`, I think it's misleading, as I would guess the method receiver would get mutated. `map` is way to confusing. Including *self* inside a method name is always somewhat confusing (self in which context?), so I would prefer not to do it. So many ideas, there are definitely a lot I would be content with, we just need to decide. ---------------------------------------- Feature #14594: Rethink yield_self's name https://bugs.ruby-lang.org/issues/14594#change-71509 * 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: