[#56333] [CommonRuby - Feature #8723][Open] Array.any? predicate returns true for empty array. — "nurettin (Nurettin Onur TUGCU)" <onurtugcu@...>
12 messages
2013/08/02
[#56346] [CommonRuby - Feature #8723] Array.any? predicate returns true for empty array.
— "nurettin (Nurettin Onur TUGCU)" <onurtugcu@...>
2013/08/03
[#56368] [ruby-trunk - Bug #8730][Open] "rescue Exception" rescues Timeout::ExitException — "takiuchi (Genki Takiuchi)" <genki@...21g.com>
15 messages
2013/08/04
[#56858] [ruby-trunk - Bug #8730] "rescue Exception" rescues Timeout::ExitException
— "nobu (Nobuyoshi Nakada)" <nobu@...>
2013/08/29
[#57017] Re: [ruby-trunk - Bug #8730] "rescue Exception" rescues Timeout::ExitException
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/09/04
2013/8/28 nobu (Nobuyoshi Nakada) <nobu@ruby-lang.org>:
[#56389] [ruby-trunk - Feature #8738][Open] Integer#single_bit? (Actually Fixnum#single_bit? and Bignum#single_bit?) — "akr (Akira Tanaka)" <akr@...>
5 messages
2013/08/05
[#56407] [ruby-trunk - misc #8741][Open] email notification on bugs.ruby-lang.org is broken — "rits (First Last)" <redmine@...>
18 messages
2013/08/05
[#56517] Re: [ruby-cvs:49638] zzak:r42496 (trunk): * lib/time.rb: [DOC] Document constants by @markijbema [Fixes GH-377] — Tanaka Akira <akr@...>
2013/8/11 <zzak@ruby-lang.org>:
3 messages
2013/08/10
[#56523] [ruby-trunk - Bug #8769][Open] [PATCH] process.c (rb_fork_internal): remove cloexec setting — "normalperson (Eric Wong)" <normalperson@...>
7 messages
2013/08/10
[#56524] [ruby-trunk - Bug #8770][Open] [PATCH] process.c: avoid EINTR from Process.spawn — "normalperson (Eric Wong)" <normalperson@...>
19 messages
2013/08/10
[#56536] [ruby-trunk - Feature #8772][Open] Hash alias #| merge, and the case for Hash and Array polymorphism — "trans (Thomas Sawyer)" <redmine@...>
24 messages
2013/08/11
[#56551] [CommonRuby - Feature #8777][Open] Process.mach_absolute_time — "tenderlovemaking (Aaron Patterson)" <tenderlove@...>
5 messages
2013/08/11
[#56567] [ruby-trunk - Feature #8780][Assigned] DBM#to_h alias for #to_hash — "zzak (Zachary Scott)" <e@...>
4 messages
2013/08/12
[#56569] [ruby-trunk - Feature #8781][Open] Use require_relative() instead of require() if possible — "ko1 (Koichi Sasada)" <redmine@...>
31 messages
2013/08/12
[#56669] [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— "trans (Thomas Sawyer)" <redmine@...>
2013/08/16
[#56674] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Aaron Patterson <tenderlove@...>
2013/08/17
On Sat, Aug 17, 2013 at 07:17:50AM +0900, trans (Thomas Sawyer) wrote:
[#56686] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Nobuyoshi Nakada <nobu@...>
2013/08/17
(13/08/17 13:13), Aaron Patterson wrote:
[#56596] Re: [ruby-trunk - Feature #8781][Open] Use require_relative() instead of require() if possible
— SASADA Koichi <ko1@...>
2013/08/13
(2013/08/12 15:35), ko1 (Koichi Sasada) wrote:
[#56582] [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— "drbrain (Eric Hodel)" <drbrain@...7.net>
2013/08/12
[#56584] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— SASADA Koichi <ko1@...>
2013/08/12
(2013/08/13 2:25), drbrain (Eric Hodel) wrote:
[#56636] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Aaron Patterson <tenderlove@...>
2013/08/16
On Tue, Aug 13, 2013 at 07:38:01AM +0900, SASADA Koichi wrote:
[#56638] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— SASADA Koichi <ko1@...>
2013/08/16
(2013/08/16 14:21), Aaron Patterson wrote:
[#56643] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Aaron Patterson <tenderlove@...>
2013/08/16
On Fri, Aug 16, 2013 at 03:00:59PM +0900, SASADA Koichi wrote:
[#56647] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2013/08/16
Em 16-08-2013 03:24, Aaron Patterson escreveu:
[#56675] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible
— Aaron Patterson <tenderlove@...>
2013/08/17
On Fri, Aug 16, 2013 at 09:35:04AM -0300, Rodrigo Rosenfeld Rosas wrote:
[#56634] [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread — "normalperson (Eric Wong)" <normalperson@...>
11 messages
2013/08/16
[#56683] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread
— SASADA Koichi <ko1@...>
2013/08/17
(2013/08/16 10:47), normalperson (Eric Wong) wrote:
[#56700] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread
— Eric Wong <normalperson@...>
2013/08/17
SASADA Koichi <ko1@atdot.net> wrote:
[#56761] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/20
Hi
[#56763] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread
— Eric Wong <normalperson@...>
2013/08/20
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
[#56658] [ruby-trunk - Feature #8796][Open] Use GMP to accelerate Bignum operations — "akr (Akira Tanaka)" <akr@...>
5 messages
2013/08/16
[#56672] Re: [ruby-cvs:49733] eregon:r42591 (trunk): * process.c (rb_clock_gettime): document CLOCK_REALTIME and — Tanaka Akira <akr@...>
2013/8/17 <eregon@ruby-lang.org>:
4 messages
2013/08/17
[#56678] Re: [ruby-cvs:49733] eregon:r42591 (trunk): * process.c (rb_clock_gettime): document CLOCK_REALTIME and
— Benoit Daloze <eregontp@...>
2013/08/17
On 17 August 2013 02:52, Tanaka Akira <akr@fsij.org> wrote:
[#56746] [ruby-trunk - Bug #8803][Open] Another buffer overflow — "user021 (a s)" <user021@...>
6 messages
2013/08/19
[#56753] [ruby-trunk - Feature #8804][Open] ONCE syntax — "ko1 (Koichi Sasada)" <redmine@...>
7 messages
2013/08/20
[#56762] [ruby-trunk - Bug #8805][Open] Ruby GC::Profiler returns incorrect info on Solaris (and relatives) — "sax (Eric Saxby)" <sax@...>
8 messages
2013/08/20
[#56780] [ruby-trunk - Feature #8809][Open] Process.clock_getres — "akr (Akira Tanaka)" <akr@...>
7 messages
2013/08/22
[#56795] [ruby-trunk - Bug #8816][Open] Tempfile.new may return the same name for parallel calls — "375gnu (Hleb Valoshka)" <redmine@...>
4 messages
2013/08/24
[#56809] [ruby-trunk - Feature #8820][Open] Speed up Array#index — "trans (Thomas Sawyer)" <redmine@...>
5 messages
2013/08/26
[#56811] Re: [ruby-trunk - Feature #8820][Open] Speed up Array#index
— Eric Wong <normalperson@...>
2013/08/26
"trans (Thomas Sawyer)" <redmine@ruby-lang.org> wrote:
[#56824] [ruby-trunk - Feature #8823][Open] Run trap handler in an independent thread called "Signal thread" — "ko1 (Koichi Sasada)" <redmine@...>
14 messages
2013/08/27
[#56825] Re: [ruby-trunk - Feature #8823][Open] Run trap handler in an independent thread called "Signal thread"
— Tanaka Akira <akr@...>
2013/08/27
2013/8/27 ko1 (Koichi Sasada) <redmine@ruby-lang.org>:
[#56850] [ruby-trunk - Feature #8823] Run trap handler in an independent thread called "Signal thread"
— "kosaki (Motohiro KOSAKI)" <kosaki.motohiro@...>
2013/08/28
[#56862] [ruby-trunk - Feature #8823][Feedback] Run trap handler in an independent thread called "Signal thread"
— "ko1 (Koichi Sasada)" <redmine@...>
2013/08/29
[#56839] [ANN] Ruby Developer Meeting 20130831 — "NARUSE, Yui" <naruse@...>
Hi,
7 messages
2013/08/28
[#57129] Re: [ANN] Ruby Developer Meeting 20130831
— "NARUSE, Yui" <naruse@...>
2013/09/11
Hi,
[#56861] [ruby-trunk - Feature #3620] Add Queue, SIzedQueue and ConditionVariable implementations in C in addition to ruby ones — "ko1 (Koichi Sasada)" <redmine@...>
6 messages
2013/08/29
[#56865] Re: [ruby-trunk - Feature #3620] Add Queue, SIzedQueue and ConditionVariable implementations in C in addition to ruby ones
— Eric Wong <normalperson@...>
2013/08/29
"ko1 (Koichi Sasada)" <redmine@ruby-lang.org> wrote:
[#56866] [ruby-trunk - Feature #8834][Open] Kernel#load_relative — "sawa (Tsuyoshi Sawada)" <sawadatsuyoshi@...>
7 messages
2013/08/30
[#56890] [ruby-trunk - Feature #8839][Open] Class and module should return the class or module that was opened — "headius (Charles Nutter)" <headius@...>
26 messages
2013/08/30
[#56894] [ruby-trunk - Feature #8840][Open] Yielder#state — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>
14 messages
2013/08/30
[#56911] [ruby-trunk - Feature #8846][Open] Publicize Module#include — "matsuda (Akira Matsuda)" <ronnie@...>
6 messages
2013/08/31
[ruby-core:56717] Re: [ruby-trunk - Feature #7739] Define Hash#| as Hash#reverse_merge in Rails
From:
David MacMahon <davidm@...>
Date:
2013-08-18 07:55:23 UTC
List:
ruby-core #56717
On Aug 17, 2013, at 5:44 PM, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> As I stated in #8772, I believe #| being implemented as #reverse_merge instead of #merge is confusing. I believe the original example in the description makes sense though.
Why do you think that...
{a:1, b:1} | {b:2, c:2) #=> {a:1, b:2, c:2} # merge-like
...is less confusing than...
{a:1, b:1} | {b:2, c:2) #=> {a:1, b:1, c:2} # reverse_merge-like
...? For conflicting keys, the reverse_merge-like behavior gives precedence to the values of the left hand side, which I find reminiscent of the short-circuit behavior of || and &&. The merge-like behavior gives precedence to the values of the right hand side, which seems unusual IMHO.
In addition to the short-circuit behavior of || and &&, Array#| also already gives precedence to the left hand side by preserving the order of the original array:
[ "a", "b", "c" ] | [ "c", "d", "a" ] #=> [ "a", "b", "c", "d" ]
> Those alias would already be useful in cases people are using reverse_merge:
>
> options.reverse_merge! a: 1
>
> options = {a: 1} | options # not exactly the same, but usually has the same effect on most well written code
But wouldn't "options |= {a: 1}" be even more concise and similar in form to the "foo ||= 1" idiom? By having Hash#| be an alias for reverse_merge, this also wouldn't be exactly the same as reverse_merge!, but I suspect it would be effectively the same for a majority of uses. For "options" being passed in as a method parameter, I think it would be better than reverse_merge! because it doesn't modify/pollute the caller's Hash. There is a performance trade off (create new object and not pollute caller's Hash vs no new object but pollute caller's Hash) that needs to be considered, but for performance sensitive cases one could use reverse_merge! explicitly.
> I'd even be fine with #>> as an alias for reverse_merge!
>
> options >>= {a: 1} # options.reverse_merge! a: 1
I'm not opposed to #>>= being reverse_merge!. I'm not thrilled with it either, but maybe it's just my C++ extraction operator days haunting me! :-)
Dave