[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66493] [ruby-trunk - misc #10549] [Open] Deprecate each_with_index and each_with_object in favor of with_index and with_object
From:
daniel@...
Date:
2014-11-26 16:12:04 UTC
List:
ruby-core #66493
Issue #10549 has been reported by Daniel Morrison. ---------------------------------------- misc #10549: Deprecate each_with_index and each_with_object in favor of with_index and with_object https://bugs.ruby-lang.org/issues/10549 * Author: Daniel Morrison * Status: Open * Priority: Normal * Assignee: Yukihiro Matsumoto * Category: syntax * Target version: current: 2.2.0 ---------------------------------------- I wonder if we can deprecate `each_with_index` and `each_with_object` and fully recommend `with_index` and `with_object` instead. I personally like the shorter forms because they hint that they can be used with more methods than simply `each`. People don't need to ask if there's a `map_with_index` method, they can just try chaining it the same way and it works! I realized this when teaching new Rubyists, because they often ask those questions. There is a negligible performance hit. Lots of code uses `each_with_index` but it is a one-character change to use `each.with_index` instead. Forgive me if this has been brought up recently, but I couldn't find any discussion on it. -- https://bugs.ruby-lang.org/