* [ruby-core:66493] [ruby-trunk - misc #10549] [Open] Deprecate each_with_index and each_with_object in favor of with_index and with_object
[not found] <redmine.issue-10549.20141126161204@ruby-lang.org>
@ 2014-11-26 16:12 ` daniel
2014-11-27 1:57 ` [ruby-core:66506] [ruby-trunk - misc #10549] " transfire
1 sibling, 0 replies; 2+ messages in thread
From: daniel @ 2014-11-26 16:12 UTC (permalink / raw
To: ruby-core
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/
^ permalink raw reply [flat|nested] 2+ messages in thread
* [ruby-core:66506] [ruby-trunk - misc #10549] Deprecate each_with_index and each_with_object in favor of with_index and with_object
[not found] <redmine.issue-10549.20141126161204@ruby-lang.org>
2014-11-26 16:12 ` [ruby-core:66493] [ruby-trunk - misc #10549] [Open] Deprecate each_with_index and each_with_object in favor of with_index and with_object daniel
@ 2014-11-27 1:57 ` transfire
1 sibling, 0 replies; 2+ messages in thread
From: transfire @ 2014-11-27 1:57 UTC (permalink / raw
To: ruby-core
Issue #10549 has been updated by Thomas Sawyer.
If Functors* (https://bugs.ruby-lang.org/issues/6594) could be built into the language proper, then what you suggest should be possible with essentially no performance penalties at all.
(* Not to be confused with the Haskell concept.)
----------------------------------------
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#change-50119
* 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/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-11-27 2:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <redmine.issue-10549.20141126161204@ruby-lang.org>
2014-11-26 16:12 ` [ruby-core:66493] [ruby-trunk - misc #10549] [Open] Deprecate each_with_index and each_with_object in favor of with_index and with_object daniel
2014-11-27 1:57 ` [ruby-core:66506] [ruby-trunk - misc #10549] " transfire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).