Issue #10095 has been updated by Matthew Kerwin.


Jihwan Song wrote:
> I wonder what is the biggest reason that yield may not be the word....
> 

My biggest concern remains that the keyword `yield` works in exactly the opposite direction from your proposed method. The keyword passes execution back up to a function from a higher scope, the method passes it down to a lower. I don't know how to clearly articulate it, but it feels completely wrong to me.

However I also have some linguistic/semantic problems, because of the definitions of the word "yield". As an intransient verb it means "surrender, or step back"; as a transient verb (with a direct object) it means "provide <that object>".

To arrive at the first definition, the subject has to be something that is active and capable of stepping back. For example a Thread, or a process handle, or something. I'd expect `Thread.current.yield` to bump the current thread back, and let any waiting threads execute.

For the second definition, you either need to tell it what to yield (as in a property accessor), or have it be obvious (for example a collection like an Array would obviously yield its members).

> puts 1.yield(2, 3) { |one, two, three| one + two + three }

To me -- knowing the definition of the word "yield", but not knowing the method -- the expression `1.yield(2, 3)` doesn't make sense. The example only works because you called the variables one, two, and three. Incidentally it's not a very good example because the arguments are provided left-to-right and used left-to-right ... (i.e. why bother, just use `puts 1 + 2 + 3`)

> [1, 2, 3, 4].select(&:odd?).yield {|x| {total: x.count, data: x}}

At first I had trouble understanding the intent of this example; to my mind Array#yield looks like some sort of #each operation, or in this case (because of the apparent aggregate "count" operation) something like #group_by

I'm starting to think a non-word like revapply is better, because it doesn't conflict with a keyword, and it doesn't carry any expectation from any natural languages. My preferences are:

* if it doesn't accept args, use #itself
* if it does accept args, call it something like #revapply, and have the non-block form return an Enumerator

----------------------------------------
Feature #10095: Object#as
https://bugs.ruby-lang.org/issues/10095#change-49008

* Author: Akira Matsuda
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: current: 2.2.0
----------------------------------------
We've had so many times of feature requests for a method similar to Object#tap that doesn't return self but returns the given block's execution result (e.g. #7388, #6684, #6721 ).

I'm talking about something like this in Ruby of course:
Object.class_eval { def as() yield(self) end }

IIRC Matz is not against introducing this feature but he didn't like any of the names proposed in the past, such as embed, do, identity, ergo, reference, yield_self, itself, apply, map, tap!, etc.

So, let us propose a new name, Object#as today.
It's named from the aspect of the feature that it gives the receiver a new name "as" a block local variable.
For instance, the code reads so natural and intuitive like this:

(1 + 2 + 3 + 4).as {|x| x ** 2}
=> 100

Array.new.as {|a| a << 1; a << 2}
=> [1, 2]

---Files--------------------------------
itself-block.patch (1.35 KB)


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