[#56329] [ruby-trunk - Bug #8722][Assigned] Refinements remain active beyond the end of an evaled string — "charliesome (Charlie Somerville)" <charliesome@...>

9 messages 2013/08/02

[#56333] [CommonRuby - Feature #8723][Open] Array.any? predicate returns true for empty array. — "nurettin (Nurettin Onur TUGCU)" <onurtugcu@...>

12 messages 2013/08/02

[#56368] [ruby-trunk - Bug #8730][Open] "rescue Exception" rescues Timeout::ExitException — "takiuchi (Genki Takiuchi)" <genki@...21g.com>

15 messages 2013/08/04

[#56407] [ruby-trunk - misc #8741][Open] email notification on bugs.ruby-lang.org is broken — "rits (First Last)" <redmine@...>

18 messages 2013/08/05

[#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

[#56544] [ruby-trunk - Bug #8774][Open] rb_file_dirname return wrong encoding string when dir is "." — jiayp@... (贾 延平) <jiayp@...>

10 messages 2013/08/11

[#56569] [ruby-trunk - Feature #8781][Open] Use require_relative() instead of require() if possible — "ko1 (Koichi Sasada)" <redmine@...>

31 messages 2013/08/12
[#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:

[#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

[#56648] [ruby-trunk - Bug #8795][Open] "Null byte in string error" on Marshal.load — "mml (McClain Looney)" <m@...>

17 messages 2013/08/16

[#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

[#56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy — "knu (Akinori MUSHA)" <knu@...>

11 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

[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) #=3D> {a:1, b:2, c:2} # merge-like

...is less confusing than...

    {a:1, b:1} | {b:2, c:2) #=3D> {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" ] #=3D> [ "a", "b", "c", "d" ]

> Those alias would already be useful in cases people are using =
reverse_merge:
>=20
> options.reverse_merge! a: 1
>=20
> options =3D {a: 1} | options # not exactly the same, but usually has =
the same effect on most well written code

But wouldn't "options |=3D {a: 1}" be even more concise and similar in =
form to the "foo ||=3D 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!
>=20
> options >>=3D {a: 1} # options.reverse_merge! a: 1


I'm not opposed to #>>=3D being reverse_merge!.  I'm not thrilled with =
it either, but maybe it's just my C++ extraction operator days haunting =
me! :-)

Dave

In This Thread