[#46918] [ruby-trunk - Bug #6820][Open] Time#to_s on NEWS — "no6v (Nobuhiro IMAI)" <nov@...>
8 messages
2012/08/01
[#46922] [ruby-trunk - Bug #6822][Open] Race Condition with Fiber and Process — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
8 messages
2012/08/02
[#46973] [ruby-trunk - Bug #6829][Open] Failure using Win32ole (happens in 1.8.7 and 1.9 — "mvanduyn (Mitch VanDuyn)" <mitch@...>
6 messages
2012/08/03
[#46974] [ruby-trunk - Bug #6830][Assigned] test failure test_constants(OpenSSL::TestConfig) [/ruby/test/openssl/test_config.rb:27] on Mac + homebrew — "kosaki (Motohiro KOSAKI)" <kosaki.motohiro@...>
17 messages
2012/08/04
[#46978] [ruby-trunk - Bug #6832][Open] Module#instance_method and Module#method_defined? act inconsistently w.r.t #respond_to_missing? — "myronmarston (Myron Marston)" <myron.marston@...>
6 messages
2012/08/04
[#46996] [ruby-trunk - Bug #6836][Assigned] Improve File.expand_path performance in Windows — "luislavena (Luis Lavena)" <luislavena@...>
15 messages
2012/08/04
[#47021] [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows
— "luislavena (Luis Lavena)" <luislavena@...>
2012/08/06
[#47045] [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows
— "h.shirosaki (Hiroshi Shirosaki)" <h.shirosaki@...>
2012/08/07
[#47036] [ruby-trunk - Feature #6841][Open] Shorthand for Assigning Return Value of Method to Self — "wardrop (Tom Wardrop)" <tom@...>
18 messages
2012/08/07
[#52968] [ruby-trunk - Feature #6841] Shorthand for Assigning Return Value of Method to Self
— "wardrop (Tom Wardrop)" <tom@...>
2013/02/27
[#47050] [ruby-trunk - Feature #6842][Open] Add Optional Arguments to String#strip — "wardrop (Tom Wardrop)" <tom@...>
10 messages
2012/08/07
[#47091] [ruby-trunk - Feature #6847][Open] Hash#extract — "citizen428 (Michael Kohl)" <citizen428@...>
10 messages
2012/08/09
[#47094] [ruby-trunk - Bug #6849][Open] Psych.load_file throws TypeError for empty file — "BrandonMathis (Brandon Mathis)" <BeMathis@...>
4 messages
2012/08/09
[#47103] [ruby-trunk - Bug #6851][Open] Result of File.stat("c:/...") is different from 1.9.3 — "phasis68 (Heesob Park)" <phasis@...>
8 messages
2012/08/10
[#47108] [ruby-trunk - Feature #6852][Open] [].transpose should behave specially — "boris_stitnicky (Boris Stitnicky)" <boris@...>
13 messages
2012/08/10
[#47138] [ruby-trunk - Bug #6861][Open] ERB::Util.escape_html is not escaping single quotes — "spastorino (Santiago Pastorino)" <santiago@...>
14 messages
2012/08/12
[#47199] [ruby-trunk - Bug #6872][Open] Array does not specify how it determines uniqueness of values — "agrimm (Andrew Grimm)" <andrew.j.grimm@...>
8 messages
2012/08/15
[#47243] [ruby-trunk - Feature #6895][Open] TracePoint API — "ko1 (Koichi Sasada)" <redmine@...>
27 messages
2012/08/20
[#47277] [ruby-trunk - Feature #6895] TracePoint API
— "trans (Thomas Sawyer)" <transfire@...>
2012/08/22
[#47254] [ruby-trunk - Feature #6895] TracePoint API
— "trans (Thomas Sawyer)" <transfire@...>
2012/08/20
[#47257] Re: [ruby-trunk - Feature #6895] TracePoint API
— SASADA Koichi <ko1@...>
2012/08/21
(2012/08/21 6:11), trans (Thomas Sawyer) wrote:
[#47287] [ruby-trunk - Feature #6910][Assigned] Loading syck's broken yaml with psych — "naruse (Yui NARUSE)" <naruse@...>
5 messages
2012/08/23
[#47309] [ruby-trunk - Bug #6929][Open] Documentation for Ripper — "zzak (Zachary Scott)" <zachary@...>
16 messages
2012/08/25
[#47322] Re: [ruby-cvs:43987] luislavena:r36811 (trunk): Improve require/File.expand_path performance on Windows — Urabe Shyouhei <shyouhei@...>
Hello Luis,
4 messages
2012/08/27
[#47345] [ruby-trunk - Feature #6946][Open] FIPS support? — "vo.x (Vit Ondruch)" <v.ondruch@...>
35 messages
2012/08/28
[#48231] [ruby-trunk - Feature #6946] FIPS support?
— "ko1 (Koichi Sasada)" <redmine@...>
2012/10/25
[#51002] [ruby-trunk - Feature #6946] FIPS support?
— "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
2012/12/20
[#51004] Re: [ruby-trunk - Feature #6946] FIPS support?
— SASADA Koichi <ko1@...>
2012/12/20
After that, I got the following error.
[#51006] Re: [ruby-trunk - Feature #6946] FIPS support?
— Martin Bo煬et <martin.bosslet@...>
2012/12/20
2012/12/20 SASADA Koichi <[email protected]>
[#47350] No tag for 1.8.7p370 on Github? — Charles Oliver Nutter <headius@...>
I was about to update JRuby's 1.8.7 stdlib, but there's no tag for
3 messages
2012/08/28
[#47367] [ruby-trunk - Bug #6950][Open] ruby-mode: comint-previous-input does not work — "cinsk (Seong-Kook Shin)" <cinsky@...>
6 messages
2012/08/30
[#47369] [ruby-trunk - Bug #6950] ruby-mode: comint-previous-input does not work
— "drbrain (Eric Hodel)" <[email protected]>
2012/08/30
[ruby-core:46946] [ruby-trunk - Feature #6808][Feedback] Implicit index for enumerations
From:
"drbrain (Eric Hodel)" <[email protected]>
Date:
2012-08-02 20:10:17 UTC
List:
ruby-core #46946
Issue #6808 has been updated by drbrain (Eric Hodel).
Status changed from Closed to Feedback
See rb_define_virtual_variable() and vm_svar_get()
----------------------------------------
Feature #6808: Implicit index for enumerations
https://bugs.ruby-lang.org/issues/6808#change-28609
Author: trans (Thomas Sawyer)
Status: Feedback
Priority: Normal
Assignee:
Category: core
Target version: 2.0.0
=begin
One of the less lovely things about Ruby's otherwise elegant enumerables is the lack of ubiquitous access to the current index. Because of this, we end up with a bevy of extra methods that are little more than counter parts and compensation for other enumerable methods to gain access to the index. Examples include, #each_with_index, #each_index and (in many extension libraries) #collect_with_index. It is all rather wasteful, inelegant, and limiting. Heaven forbid we need a #select_with_index, or some other uncommon case.
No doubt this has had some discussion long in the past, but I would like revisit and offer a bnew more concrete proposal...
Thanks to Enumerator, we can now at least do:
[:a,:b,:c].each_with_index.map{ |e, i| [i, e] }
That's great, but it has obvious shortcomings. It's long winded and it has the overhead of an Enumerator object. Ideally we would want to do this instead:
[:a,:b,:c].map{ |e| [$i, e] }
Where $i is the implicit index. Now a global variable is surely the simplest solution. But, I can understand that some might object to the use of a global variable, despite the fact that this approach is common with regexp matches like $1, $2, etc. In that case, we could designate a new keyword. Lets call it `index`.
[:a,:b,:c].map{ |e| [index, e] }
We might suffer a conflict here however if someone has already used "index" as a block argument. In that case we would need Ruby to allow it to be overridden, in the same sense that one can define a public method called `class`, even though `class` is a keyword in other contexts.
If this were all that we gained then I say it is a victory, but I'd like to consider also that we go a step further, and instead of having just "index", we have an iterative object. After all Ruby is an OOPL. In this case, the keyword would be `it` and we could do:
[:a,:b,:c].map{ |e| [it.index, e] }
The nice thing about `it` is that it can have a few other useful methods to improve readability of code, such as `it.first?` and `it.last?` (if size is known for the enumerable). I think this is awesome solution that grants the most readability and flexibility to the language.
Of course, having an iteration object might bring up concerns about performance, since it will add overhead to create a new iteration instance with every pass. This can be addressed by having the object be mutable, so all that needs to change is the index in the same object. A minor downside here, an `it` can't be stored by reference between passes (e.g. `prev_it = it`), but knowing this, #dup could be used if that was really necessary. If that isn't good enough to curb performance concerns, I would suggest a means of indicating the `it` object be made available. We don't want to drag Enumerator into this so `map.it{...}` is not the solution, but perhaps Ruby could recognize `;it` at the end of block arguments?
[:a,:b,:c].map{ |e; it| [it.index, e] }
Maybe that syntax can't work, but surely something along these lines could. Personally, I doubt the overhead of mutable `it` is too much, but just in case.
To summarize, I propose an implicit mutable iteration object called `it` that allows access to the enumerations index, plus convenience methods for querying the index. Or, if that is considered too much, then at least an implicit index, either as a global variable or a special keyword. Any of these choices would be a marked improvement, allowing us to avoid the endless proliferation of `_with_index` methods.
=end
--
http://bugs.ruby-lang.org/