[#56965] [ruby-trunk - Bug #8852][Open] Synology build of ruby-2.0.0-p247 is failing — "barbecuesteve (Steve Sparks)" <sparks@...>

12 messages 2013/09/02

[#57051] [ruby-trunk - Bug #8872][Open] Case statements do not honor a refinement of the '===' method — "jconley88 (Jon Conley)" <schnozberries@...>

21 messages 2013/09/07

[#57058] [ruby-trunk - Bug #8875][Open] Select is not usable with SSLSocket — "headius (Charles Nutter)" <headius@...>

11 messages 2013/09/07

[#57074] [ruby-trunk - Bug #8879][Open] String#to_r fails after moving ruby to other OSX system — "mpapis (Michal Papis)" <mpapis@...>

12 messages 2013/09/08

[#57092] [ruby-trunk - Bug #8883][Open] Rational canonicalization unexpectedly converts to Fixnum — "melquiades (Paul Cantrell)" <cantrell@...>

16 messages 2013/09/09

[#57109] [ruby-trunk - Bug #8886][Open] TracePoint API inconsistence when raise used — deivid (David Rodríguez) <deivid.rodriguez@...>

14 messages 2013/09/10

[#57111] [ruby-trunk - Feature #8887][Open] min(n), max(n), min_by(n), max_by(n) — "akr (Akira Tanaka)" <akr@...>

13 messages 2013/09/10

[#57131] [ruby-trunk - Feature #8895][Open] Destructuring Assignment for Hash — "chendo (Jack Chen)" <ruby-lang@...>

19 messages 2013/09/11

[#57186] [ruby-trunk - Feature #8909][Open] Expand "f" frozen suffix to literal arrays and hashes — "headius (Charles Nutter)" <headius@...>

37 messages 2013/09/14

[#57262] [ruby-trunk - Feature #8921][Open] Allow select, reject, etc to accept a regex — "kyledecot (Kyle Decot)" <kyle.decot@...>

13 messages 2013/09/18

[#57273] [ruby-trunk - Feature #8923][Open] Frozen nil/true/false — "ko1 (Koichi Sasada)" <redmine@...>

13 messages 2013/09/19

[#57353] [ruby-trunk - Feature #8948][Open] Frozen regex — "sawa (Tsuyoshi Sawada)" <sawadatsuyoshi@...>

19 messages 2013/09/24

[#57385] [ruby-trunk - Bug #8953][Open] `str =~ /pattern/` does not call =~ method if (1) str is a String, (2) /pattern/ is a Regexp literal — "gfx (Goro Fuji)" <gfuji@...>

12 messages 2013/09/26

[#57396] [ruby-trunk - Feature #8956][Open] Allow hash members delimited by \n inside of {} — "adamdunson (Adam Dunson)" <adam@...>

20 messages 2013/09/26

[ruby-core:57031] [ruby-trunk - Feature #7292] Enumerable#to_h

From: "boris_stitnicky (Boris Stitnicky)" <boris@...>
Date: 2013-09-05 02:14:08 UTC
List: ruby-core #57031
Issue #7292 has been updated by boris_stitnicky (Boris Stitnicky).


I think that there are two basic possibilities for Enumerable#to_h behavior:

Strict:
[[:a, 1], ["b", 2]].to_h #=> { :a => 1, "b" => 2 }
# Anything else raises a TypeError:
[[:a], ["b", 2]].to_h #=> TypeError
[[:a, 1], ["b", 2, 3].to_h #=> TypeError

Lax:
[[:a], [:b,1,2], [:c,3]].to_h #=> {:a=>[], :b=>[1,2], :c=>[3]}

"Strict" means, that the method strictly requires the arguments to be size 2 arrays. "Lax" means,
that the arguments are allowed to be arrays of any size greater of equal to 1.

In my library, I found it useful with plenty of usecases to also define Enumerable#>> as follows:
module Enumerable; def >> other; Hash[ zip other ] end end
[:a, :b, :c] >> [1, 2, 3] #=> {a: 1, b: 2, c: 3}

Additionally, I enjoyed to alias #first and #drop(1) as Lispy #car and #cdr:
module Enumerable; def car; first end end
[:a, :b, :c].car #=> :a
module Enumerable; def cdr; drop 1 end end
[:a, :b, :c].cdr #=> [:b, :c]

With these, the "lax" version of the proposed Enumerable#to_h I enjoy to write as:
x = [[:a], [:b, 1, 2], [:c, 3]]
x.map( &:car ) >> x.map( &:cdr ) # <-- This is my opinion what Enumerable#to_h should do.

The last line above is what I think that Enumerable#to_h should do. I realize that this
opinion of mine directly contradicts with what Matz said earlier. The argument for it goes
somehow like this:

Since there are two basic possibilities for Enumerable#to_h behavior, and the strict one is
already available as Hash[...], Enumerable#to_h should do the other useful thing: The lax version.

I noticed the same design pattern between #to_i and Integer(...): Both are useful, but they do
not do the same thing. Is there a weakness in this line of reasoning?




----------------------------------------
Feature #7292: Enumerable#to_h
https://bugs.ruby-lang.org/issues/7292#change-41627

Author: marcandre (Marc-Andre Lafortune)
Status: Open
Priority: Normal
Assignee: marcandre (Marc-Andre Lafortune)
Category: core
Target version: next minor


Now that #to_h is the official method for explicit conversion to Hash, we should also add

	Enumerable#to_h: Returns a hash for the yielded key-value pairs.

	  [[:name, 'Joe Smith'], [:age, 42]].to_h # => {name: 'Joe Smith', age: 42}


With the Ruby tradition of succint documentation I suggest the documentation talk about key-value pairs and there is no need to be explicit about the uninteresting cases like:

    (1..3).to_h           # => {1 => nil, 2 => nil, 3 => nil}
    [[1, 2], [1, 3]].to_h # => {1 => 3}
    [[1, 2], []].to_h     # => {1 => 2, nil => nil}

I see some reactions of people reading about the upcoming 2.0 release like this one:
http://globaldev.co.uk/2012/11/ruby-2-0-0-preview-features/#dsq-comment-body-700242476



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

In This Thread