[#48745] [ruby-trunk - Bug #7267][Open] Dir.glob on Mac OS X returns unexpected string encodings for unicode file names — "kennygrant (Kenny Grant)" <kennygrant@...>

17 messages 2012/11/02

[#48773] [ruby-trunk - Bug #7269][Open] Refinement doesn't work if using locate after method — "ko1 (Koichi Sasada)" <redmine@...>

12 messages 2012/11/03

[#48847] [ruby-trunk - Bug #7274][Open] UnboundMethods should be bindable to any object that is_a?(owner of the UnboundMethod) — "rits (First Last)" <redmine@...>

21 messages 2012/11/04

[#48854] [ruby-trunk - Bug #7276][Open] TestFile#test_utime failure — "jonforums (Jon Forums)" <redmine@...>

14 messages 2012/11/04

[#48988] [ruby-trunk - Feature #7292][Open] Enumerable#to_h — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>

40 messages 2012/11/06

[#48997] [ruby-trunk - Feature #7297][Open] map_to alias for each_with_object — "nathan.f77 (Nathan Broadbent)" <nathan.f77@...>

19 messages 2012/11/06

[#49001] [ruby-trunk - Bug #7298][Open] Behavior of Enumerator.new different between 1.9.3 and 2.0.0 — "ayumin (Ayumu AIZAWA)" <ayumu.aizawa@...>

12 messages 2012/11/06

[#49018] [ruby-trunk - Feature #7299][Open] Ruby should not completely ignore blocks. — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>

13 messages 2012/11/07

[#49044] [ruby-trunk - Bug #7304][Open] Random test failures around test_autoclose_true_closed_by_finalizer — "luislavena (Luis Lavena)" <luislavena@...>

11 messages 2012/11/07

[#49196] [ruby-trunk - Feature #7322][Open] Add a new operator name #>< for bit-wise "exclusive or" — "alexeymuranov (Alexey Muranov)" <redmine@...>

18 messages 2012/11/10

[#49211] [ruby-trunk - Feature #7328][Open] Move ** operator precedence under unary + and - — "boris_stitnicky (Boris Stitnicky)" <boris@...>

20 messages 2012/11/11

[#49229] [ruby-trunk - Bug #7331][Open] Set the precedence of unary `-` equal to the precedence `-`, same for `+` — "alexeymuranov (Alexey Muranov)" <redmine@...>

17 messages 2012/11/11

[#49256] [ruby-trunk - Feature #7336][Open] Flexiable OPerator Precedence — "trans (Thomas Sawyer)" <transfire@...>

18 messages 2012/11/12

[#49354] review open pull requests on github — Zachary Scott <zachary@...>

Could we get a review on any open pull requests on github before the

12 messages 2012/11/15
[#49355] Re: review open pull requests on github — "NARUSE, Yui" <naruse@...> 2012/11/15

2012/11/15 Zachary Scott <zachary@zacharyscott.net>:

[#49356] Re: review open pull requests on github — Zachary Scott <zachary@...> 2012/11/15

Ok, I was hoping one of the maintainers might want to.

[#49451] [ruby-trunk - Bug #7374][Open] File.expand_path resolving to first file/dir instead of absolute path — mdube@... (Martin Dubé) <mdube@...>

12 messages 2012/11/16

[#49463] [ruby-trunk - Feature #7375][Open] embedding libyaml in psych for Ruby 2.0 — "tenderlovemaking (Aaron Patterson)" <aaron@...>

21 messages 2012/11/16
[#49494] [ruby-trunk - Feature #7375] embedding libyaml in psych for Ruby 2.0 — "vo.x (Vit Ondruch)" <v.ondruch@...> 2012/11/17

[#49467] [ruby-trunk - Feature #7377][Open] #indetical? as an alias for #equal? — "aef (Alexander E. Fischer)" <aef@...>

13 messages 2012/11/17

[#49558] [ruby-trunk - Bug #7395][Open] Negative numbers can't be primes by definition — "zzak (Zachary Scott)" <zachary@...>

10 messages 2012/11/19

[#49566] [ruby-trunk - Feature #7400][Open] Incorporate OpenSSL tests from JRuby. — "zzak (Zachary Scott)" <zachary@...>

11 messages 2012/11/19

[#49770] [ruby-trunk - Feature #7414][Open] Now that const_get supports "Foo::Bar" syntax, so should const_defined?. — "robertgleeson (Robert Gleeson)" <rob@...>

9 messages 2012/11/20

[#49950] [ruby-trunk - Feature #7427][Assigned] Update Rubygems — "mame (Yusuke Endoh)" <mame@...>

17 messages 2012/11/24

[#50043] [ruby-trunk - Bug #7429][Open] Provide options for core collections to customize behavior — "headius (Charles Nutter)" <headius@...>

10 messages 2012/11/24

[#50092] [ruby-trunk - Feature #7434][Open] Allow caller_locations and backtrace_locations to receive negative params — "sam.saffron (Sam Saffron)" <sam.saffron@...>

21 messages 2012/11/25

[#50094] [ruby-trunk - Bug #7436][Open] Allow for a "granularity" flag for backtrace_locations — "sam.saffron (Sam Saffron)" <sam.saffron@...>

11 messages 2012/11/25

[#50207] [ruby-trunk - Bug #7445][Open] strptime('%s %z') doesn't work — "felipec (Felipe Contreras)" <felipe.contreras@...>

19 messages 2012/11/27

[#50424] [ruby-trunk - Bug #7485][Open] ruby cannot build on mingw32 due to missing __sync_val_compare_and_swap — "drbrain (Eric Hodel)" <drbrain@...7.net>

15 messages 2012/11/30

[#50429] [ruby-trunk - Feature #7487][Open] Cutting through the issues with Refinements — "trans (Thomas Sawyer)" <transfire@...>

13 messages 2012/11/30

[ruby-core:49215] Re: [ruby-trunk - Feature #7241] Enumerable#to_h proposal

From: "Martin J. Dürst" <duerst@...>
Date: 2012-11-11 08:58:56 UTC
List: ruby-core #49215
On 2012/11/11 0:47, jballanc (Joshua Ballanco) wrote:
>
> Issue #7241 has been updated by jballanc (Joshua Ballanco).
>
>
> =begin
> Clojure has a function (({into})) that might fit the bill.

This indeed looks very promising.

> An equivalent Ruby implementation might look something like the following:
>
>      class Hash
>        alias :<<  :merge!
>      end

I might be wrong, but my guess is that constructing lots of 
one-key/value hashes isn't very efficient. Two-element arrays should be 
quite a bit more efficient. So we could define this as follows (in the 
end in C, but here just in Ruby):

class Hash
   def << (other)
     case other.class
     when Array
       store(other[0], other[1])
     when Hash
       merge! other
     end
     self
   end
end

(some additional tweaks may be needed for Array-like and Hash-like objects).


>      module Enumerable
>        def into(coll)
>          coll = coll.dup
>          each do |elem|
>            coll<<  yield(elem)
>          end
>          coll
>        end
>      end
>
>      chars = (97..107).into({}) { |i| { i =>  i.chr } }
>      p chars
>
>      require 'prime'
>      prime_chars = chars.into([]) { |k, v| k.prime? ? v : nil }
>      p prime_chars.compact

It would be great to have a version that avoided "compact". Or maybe 
only that version would be okay? This would use "concat" instead of 
merge! (with Hash#concat an alias for Hash#merge!). Because neither 
Hashes nor Strings can be nested, there would actually not be any 
difference for those, but for Array, the preceeding code could be 
simplified to:

       require 'prime'
       prime_chars = chars.into___([]) { |k, v| k.prime? ? [v] : [] }

I often want a "collect" method where I'm not forced to collect exactly 
one item per item of the original collection. If collect weren't an 
alias to map, I think it would even make a lot of sense to use the word 
"collect" for this (map: one-to-one, collect: one-to-many).

Regards,    Martin.


>      char_string = chars.into("") { |k, v| "#{k}=>#{v}, " }
>      p char_string
> =end
>
> ----------------------------------------
> Feature #7241: Enumerable#to_h proposal
> https://bugs.ruby-lang.org/issues/7241#change-32755
>
> Author: nathan.f77 (Nathan Broadbent)
> Status: Rejected
> Priority: Normal
> Assignee:
> Category: core
> Target version:
>
>
> I often use the `inject` method to build a hash, but I always find it annoying when I need to return the hash at the end of the block.
> This means that I often write code like:
>
>      [1,2,3,4,5].inject({}) {|hash, el| hash[el] = el * 2; hash }
>
> I'm proposing an `Enumerable#to_h` method that would let me write:
>
>      [1,2,3,4,5].to_h {|h, el| h[el] = el * 2 }
>
>
> I saw the proposal at http://bugs.ruby-lang.org/issues/666, but I would not be in favor of his implementation.
> I believe the implementation should be similar to `inject`, so that the hash object and next element are passed to the block. The main difference to the `inject` method is that we would be modifying the hash in place, instead of relying on the block's return value.
>
> As well as providing support for the case above, I have also considered other cases where the `to_h` method would be useful.
> I thought it would be useful if symmetry were provided for the `Hash#to_a` method, such that:
>
>      hash.to_a.to_h == hash  # =>  true
>
> (See example 2)
>
>
> I've allowed developers to provide a symbol instead of a block, so that each element in the collection will be passed to that named method. (See example 3)
>
> Finally, hashes can be given a default value, or a Proc that returns the default value. (See examples 4&  5)
>
>
> Heres an example implementation that I would be happy to rewrite in C if necessary:
>
>
>      module Enumerable
>        def to_h(default_or_sym = nil)
>          if block_given?
>            hash = if Proc === default_or_sym
>              Hash.new(&default_or_sym)
>            else
>              Hash.new(default_or_sym)
>            end
>            self.each do |el|
>              yield hash, el
>            end
>          elsif !default_or_sym.nil?
>            hash = {}
>            self.each do |el|
>              hash[el] = el.send(default_or_sym)
>            end
>          else
>            return Hash[*self.to_a.flatten(1)]
>          end
>          hash
>        end
>      end
>
>
> Examples
> ----------------------------------------------
>
>
> # 1) Build a hash from array elements
>
>      [1,2,3,4,5].to_h {|h, el| h[el] = el * 2 }
>
> =>  {1=>2, 2=>4, 3=>6, 4=>8, 5=>10}
>
>
> # 2) Provides symmetry for Hash.to_a (i.e. you can call hash.to_a.to_h)
>
>      [[1, 2], [3, 4], [5, 6]].to_h
>
> =>  {1=>2, 3=>4, 5=>6}
>
>
> # 3) Build a hash by calling a method on each array element
>
>      ["String", "Another String"].to_h(:size)
>
> =>  {"String"=>6, "Another String"=>14}
>
>
> # 4) Hash with default value
>
>      [4,5,6,5].to_h(0) {|h, el| h[el] += el }
>
> =>  {4=>4, 5=>10, 6=>6}
>
>
> # 5) Hash with default value returned from Proc
>
>      default_proc = ->  hash, key { hash[key] = "go fish: #{key}" }
>      [4,5,6].to_h(default_proc) {|h, el| h[el].upcase! }
>
> =>  {4=>"GO FISH: 4", 5=>"GO FISH: 5", 6=>"GO FISH: 6"}
>
>
>
> Thanks for your time, and please let me know your thoughts!
>
>
> Best,
> Nathan Broadbent
>
>

In This Thread