Project

General

Profile

Actions

Feature #709

closed

Enumerator#+

Added by candlerb (Brian Candler) over 15 years ago. Updated over 5 years ago.

Status:
Rejected
Target version:
[ruby-core:19681]

Description

=begin
Enumerators could be directly composable:

class Enumerator
def +(other)
Enumerator.new do |y|
each { |e| y << e }
other.each { |e| y << e }
end
end
end

if FILE == $0
a = (1..3).to_enum + (10..12).to_enum + (17..20).to_enum
a.each { |i| puts i }
end

The only problem I can see here is that this might open the floodgates to requests for more methods such as & and |, and it's not clear how those would behave. (Personally I'd go for a merge which compares the head items from each of the operands, which assumes that the operands are already in sorted order, but others may disagree)
=end


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #15144: Enumerator#chainClosedknu (Akinori MUSHA)Actions
Actions #1

Updated by candlerb (Brian Candler) over 15 years ago

=begin
For clarity, here's what that example outputs:

$ ruby19 -v
ruby 1.9.1 (2008-10-28 revision 19983) [i686-linux]
$ ruby19 enum_plus.rb
1
2
3
10
11
12
17
18
19
20
$

=end

Actions #2

Updated by ko1 (Koichi Sasada) over 15 years ago

  • Assignee set to matz (Yukihiro Matsumoto)

=begin

=end

Actions #3

Updated by knu (Akinori MUSHA) over 15 years ago

  • Status changed from Open to Rejected
  • Assignee changed from matz (Yukihiro Matsumoto) to knu (Akinori MUSHA)

=begin
To tell the truth, I was also tempted to add something like that and
you are not alone.

You might as well add:

class Enumerator
alias * cycle

def -@
Enumerator.new { |y| to_a.reverse_each { |i| y << i } }
end
end

and have fun with them as follows:

e = -[1,4,7].each * 3 + ("a".."c").each
p e.to_a #=> [3, 2, 1, 3, 2, 1, 3, 2, 1, "a", "b", "c"]

However, I am yet to think that even the addition of enumerators is so
commonly in need.

Besides, as you said, operators must be carefully chosen and defined so
that they work consistently and systematically and they look intuitive
and practical, all at the same time. We should also think how other
types of iterators should be introduced, such as bidirectional iterators
and indexable iterators, before defining a variety of operators for
the current Enumerator.

So, my answer here, for now, is the block based enumerator. Just as you
have aptly shown, you can define anything you like with it without the
need for predefined operators.
=end

Actions #4

Updated by knu (Akinori MUSHA) over 5 years ago

Updated by knu (Akinori MUSHA) over 5 years ago

  • Description updated (diff)

I've become positive about this proposal after experiences with potential use cases.

In today's developer meeting, Matz approved this proposal, so I'm going to start working on this!

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0