[#64703] Add `Hash#fetch_at` (issue #10017) — Wojtek Mach <wojtek@...>
Hey guys
1 message
2014/09/01
[#64711] [ruby-trunk - Bug #10193] [Closed] TestIO#test_readpartial_locktmp fails randomly — nobu@...
Issue #10193 has been updated by Nobuyoshi Nakada.
3 messages
2014/09/02
[#64744] [ruby-trunk - Bug #10202] [Open] TestBenchmark#test_realtime_output breaks on ARM — v.ondruch@...
Issue #10202 has been reported by Vit Ondruch.
3 messages
2014/09/03
[#64823] documenting constants — Xavier Noria <fxn@...>
I am writing a Rails guide about constant autoloading in Ruby on
5 messages
2014/09/07
[#64838] [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus — ko1@...
Issue #10212 has been reported by Koichi Sasada.
6 messages
2014/09/08
[#64858] Re: [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus
— Eric Wong <normalperson@...>
2014/09/08
rb_env_t may use a flexible array, helps a little even on my busy system:
[#64871] Re: [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus
— SASADA Koichi <ko1@...>
2014/09/08
(2014/09/08 19:48), Eric Wong wrote:
[#64972] [ruby-trunk - Bug #10231] [Open] Process.detach(pid) defines new singleton classes every call — headius@...
Issue #10231 has been reported by Charles Nutter.
3 messages
2014/09/11
[#64980] [ruby-trunk - Bug #10212] MRI is not for lambda calculus — ko1@...
Issue #10212 has been updated by Koichi Sasada.
4 messages
2014/09/12
[#65142] [ruby-trunk - Feature #10267] [Open] Number of processors — akr@...
Issue #10267 has been reported by Akira Tanaka.
4 messages
2014/09/20
[#65144] Re: [ruby-trunk - Feature #10267] [Open] Number of processors
— Eric Wong <normalperson@...>
2014/09/20
akr@fsij.org wrote:
[#65210] [ruby-trunk - misc #10278] [Assigned] [RFC] st.c: use ccan linked list — nobu@...
Issue #10278 has been updated by Nobuyoshi Nakada.
3 messages
2014/09/22
[ruby-core:65169] [ruby-trunk - Feature #10095] Object#as
From:
matthew@...
Date:
2014-09-20 11:54:14 UTC
List:
ruby-core #65169
Issue #10095 has been updated by Matthew Kerwin.
Jihwan Song wrote:
> Matt,
>
> I guess I had totally different understanding of the Ruby keyword 'yield'. When I first saw the language years back, at the statement saying 'yield' I was speaking to myself "yield what??" -- I always took it as meaning "produce" ( yeah, I always thought the 'yield' was a bad choice as the keyword for it in Ruby because it can be confused with other meanings of the word 'yield'... well, on the other hand, it may be the best word for it for the same reason :) )
How often do you see the keyword `yield` without arguments? Even in your examples you are clearly passing arguments (direct objects) to it.
> Once I understand the language, I always took it as transient verb with implied direct object, which is the block passed to it.
But you don't pass a block to the keyword; you're not saying "yield this block." Rather, you're instructing the scope (i.e. the function) to yield *values* (direct objects) *to the block* (indirect object).
Translating from Ruby to English:
~~~
def foo *a, &b
yield *a
end
~~~
...becomes...
"foo, yield *a to &b"
So the subject is the function, the direct object is the args (which defaults to an empty list), and the indirect object is the block. If you explicitly name the subject, that subject has to "possess" the direct object, and then yield it to the indirect object (e.g. a function can resolve the variable `a` to an object and yield it; an array can resolve the index 0 to an object and yield it; etc.)
> Actually, the examples I included runs beautifully in current definition of Ruby language. The point of my sample code is to show you that it is totally coherent with current definition of Ruby language.
I still assert that it isn't coherent. Since the method receiver is the first (or only) of the direct objects, the message you are sending it should be "be yielded ...", not "yield".
> Now, with the extension of current work yield, without hurting the original meaning both in English and Ruby, it now can specify subject and direct object explicitly... that's all.
No, because `1.yield(2)` means: "1, yield the value 2 to ..." which is nonsensical. What you want to say is: "ruby, yield the values (1,2) to ..." or put another way "1, be yielded along with 2 to ..."
Best to leave the word "yield" out of the verb altogether.
----------------------------------------
Feature #10095: Object#as
https://bugs.ruby-lang.org/issues/10095#change-49011
* 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/