[#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:57019] [ruby-trunk - Feature #7292] Enumerable#to_h

From: "alexeymuranov (Alexey Muranov)" <redmine@...>
Date: 2013-09-04 19:17:08 UTC
List: ruby-core #57019
Issue #7292 has been updated by alexeymuranov (Alexey Muranov).


=begin
Matz,

it was just a reminder about (({#assoc})) and (({#rassoc})), sorry if it was redundant.  IMO, they serve a similar purpose to (({#to_h})): they allow to use an ((*array of two-element arrays*)) as a storage where selection "by key" or "by value" is possible.

I think, if (({#assoc})) and (({#to_h})) were introduced simultaneously, the following would have given identical results:

  [[:a, 1], [:a, 2]].assoc(:a)      # => [:a, 1]
  [[:a, 1], [:a, 2]].to_h.assoc(:a) # => [:a, 2] with any of the suggested above implementations

I probably didn't used "consistent" correctly, not in mathematical sense.  I meant something closer to "natural": that as many operations or ((*diagrams*)) ((*commute*)) as possible.  That is, when appropriate, the result of  (({x.foo.bar}))  should be the same as that of  (({x.bar})),  or, if  (({#foo}))  applies some "essential" transformation to  (({x})),  but there exists an operation  (({#baz}))  applicable to  (({x.bar}))  that is a "counterpart" of  (({#foo})),  then it would be nice if  (({x.foo.bar})) was identical with (({x.bar.baz})), unless it makes sense to have them different.  Here are the corresponding "commuting diagrams" (not exactly, but this gives the idea):

  x -- #foo --> x.foo
   \            |
    #bar        #bar
     \          |
      J         V
     x.bar = x.foo.bar

    x --------- #foo ---------> x.foo
    |                              |
    #bar                           #bar
    |                              |
    V                              V
  x.bar -- #baz --> x.bar.baz = x.foo.bar

I do not insist, i am just trying to explain what i meant.
=end

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

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