8 Jan
2023
8 Jan
'23
10:06 a.m.
Issue #19324 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
8 Jan
8 Jan
7:17 p.m.
New subject: [ruby-core:111743] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by sawa (Tsuyoshi Sawada).
[T]wo methods [...] do completely different things and
differ by one letter, both being somewhat vague verbs
`produce` is (most of the time) a verb or (sometimes) a noun. `product` is no doubt a
noun.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101146
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
10:07 p.m.
New subject: [ruby-core:111744] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by duerst (Martin Dürst).
For `product`, one important issue not yet mentioned here is whether it's calculated
on e.g. two or three separate arrays, where making the first of the arrays the receiver,
or whether it's calculated on an array of arrays where the first of the arrays
doesn't have any special significance.
In the second case, writing e.g.
`[0, 1].product([0, 1], [0, 1])` feels rather inappropriate. But this case in my
experience is actually rather more frequent than having a first array that is in some way
special. Even more, if the array of arrays is already a variable, it gets rather
involved:
```
array_of_arrays = [[0, 1]] * 3
# => [[0, 1], [0, 1], [0, 1]]
array_of_arrays.first.product(*array_of_arrays.drop(1))
# =>
# [[0, 0, 0],
# [0, 0, 1],
# [0, 1, 0],
# [0, 1, 1],
# [1, 0, 0],
# [1, 0, 1],
# [1, 1, 0],
# [1, 1, 1]]
```
`Enumerator.product` makes that more straightforward:
`Enumerator.product(*array_of_arrays)`. (In my purely personal opinion, the need for the
`*` is still a nuissance, but only a small one.)
Having these two invocations distinguished by whether the method is an instance method or
a class method to some extent makes sense, although being able to use the instance method
directly on an array of arrays might also make some sense. Having the instance method on
Array and the class method on Enumerator seems something that could be improved without
any backwards compatibility problems.
That still leaves the problem that I really would like to write `array_of_arrays.product`,
in particular in a method chain. That will be difficult to get to because of backward
compatibility problems.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101147
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
10 Jan
10 Jan
10:09 p.m.
New subject: [ruby-core:111776] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by mame (Yusuke Endoh).
As @duerst mentioned, it is sometimes noted that `Array#product` and `Array#zip` are ugly
and inconvenient due to its asymmetry.
https://bugs.ruby-lang.org/issues/8970
https://bugs.ruby-lang.org/issues/6499
I don't think we have to inherit the asymmetry when introducing a new
`Enumerator#product`.
As for the name issue, I believe `Enumerator.product` is definitely the best name. The
term is widely used for this operation in math and computer science, specifically set
theory. If we must change either, we should rethink `produce`. I personally don't
think it is worth changing, though.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101189
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
11 Jan
11 Jan
3:47 a.m.
New subject: [ruby-core:111779] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
First, I just looked through codebases at my disposal, and it seems that for `product`
there are at least as many examples where the first argument _has_ a special meaning as
those where it doesn't. Examples are like:
```ruby
user_names.product([''])
# => [['name1', ''], ['name2' ''], ...]
# this is the format some API requires, and .product is a simplest way to produce it
possible_methods.product(possible_arguments)
#=> list of test cases to check the stability of methods for all known arguments
users.product(%i[original thumbnail]) #=> then produce big and small avatar for all of
them
```
Or, in `ruby/lib`, there are exactly 3 entries, of which _two_ have distinct arguments:
```
$ grep -F "product(" lib -r
lib/did_you_mean/tree_spell_checker.rb: states =
plausibles[0].product(*plausibles[1..-1])
lib/bundler/spec_set.rb: handled = ["bundler"].product(platforms).map {|k|
[k, true] }.to_h
lib/bundler/spec_set.rb: deps = dependencies.product(platforms)
```
Rubocop (both entries have distinct arguments):
```
$ grep -F "product(" {lib,spec} -r
lib/rubocop/config_obsoletion.rb: cops.product(parameters).map do |cop,
parameter|
spec/rubocop/cop/style/self_assignment_spec.rb: %i[+ - * ** / | & ||
&&].product(['x', '@x', '@@x']).each do |op, var|
```
**But second and more important,** the same argument (it is a method that operates on
homogenous parameters, why it belongs to the first parameter?..) can be applied to a lot
of methods. Like the aforementioned `Array#zip`, or `Hash#merge` (there are a lot of cases
when we are just merging several homogenous hashes), or, well, even `a + b`!
But multi-parameter methods consistently belong to their first parameters throughout Ruby,
save for several methods in `Math` maybe (which, honestly, always felt like a compromise
or legacy).
So, the question is: is there a design plan to change _many_ of the methods
(`Array.product` in addition to `Enumerable.product`, `Array.zip`, `Hash.merge`, I dunno,
maybe even `Array.concat`?..) to the `Module.method` protocol? Or, would
`Enumerable.product` be the **only** sore exclusion from what is consistently done
throughout Ruby?..
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101193
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
10:48 a.m.
New subject: [ruby-core:111781] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by sawa (Tsuyoshi Sawada).
zverok (Victor Shepelev) wrote in #note-4:
[I]s there a design plan to change _many_ of the
methods (`Array.product` in addition to `Enumerable.product`, `Array.zip`, `Hash.merge`, I
dunno, maybe even `Array.concat`?..) to the `Module.method` protocol? Or, would
`Enumerable.product` be the **only** sore exclusion from what is consistently done
throughout Ruby?
I believe quite many people are in favor of `Array.product` and/or `Array.zip`. I wish the
implementation/existence of `Enumerator.product` will work as a pressure towards
implementing these methods as well. However, I do not think many other methods like those
you mention would need to be handled similarly for the sake of consistency; (i)
`Array#product` and `Array#zip` are different from (ii) `Hash#merge` and `Array#concat`.
The (ii) methods with multiple arguments are nothing more than a repetition of binary
operations (and furthermore, they are associative):
```ruby
[1, 2, 3].concat([4, 5, 6], [7, 8, 9]) ==
[1, 2, 3].concat([4, 5, 6]).concat([7, 8, 9]) ==
[1, 2, 3].concat([4, 5, 6].concat([7, 8, 9]))
# => [1, 2, 3, 4, 5, 6, 7, 8, 9]
{a: 1}.merge({b: 2}, {c: 3}) ==
{a: 1}.merge({b: 2}).merge({c: 3}) ==
{a: 1}.merge({b: 2}.merge({c: 3}))
# => {:a=>1, :b=>2, :c=>3}
```
whereas the (i) methods are not:
```ruby
[1, 2].zip([3, 4], [5, 6]) # => [[1, 3, 5], [2, 4, 6]]
[1, 2].zip([3, 4]).zip([5, 6]) # => [[[1, 3], 5], [[2, 4], 6]]
[1, 2].zip([3, 4].zip([5, 6])) # => [[1, [3, 5]], [2, [4, 6]]]
[1, 2, 3].zip([4, 5, 6], [7, 8, 9]) # => [[1, 4, 7], [2, 5, 8], [3, 6, 9]]
[1, 2, 3].zip([4, 5, 6]).zip([7, 8, 9]) # => [[[1, 4], 7], [[2, 5], 8], [[3, 6], 9]]
[1, 2, 3].zip([4, 5, 6].zip([7, 8, 9])) # => [[1, [4, 7]], [2, [5, 8]], [3, [6, 9]]]
```
Thus, the (i) methods with multiple arguments have a firm position. They have stronger
motivation to exist as an independent concept, and accordingly, stronger motivation for
their receiver and the arguments to be treated symmetrically.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101194
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
20 Jan
20 Jan
7:48 p.m.
New subject: [ruby-core:111946] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by ttilberg (Tim Tilberg).
I believe quite many people are in favor of
Array.product and/or Array.zip.
I personally find this surprising! It goes against what I find to be two of Ruby’s best
design philosophies against Python:
Instance method versions are more discoverable. “What can I do with this object?” was how
I learned how to be fluent in Ruby. I’ve always appreciated the consistency of “everything
I do, is a method on this object”. Notably, compared to Python, you aren’t faced with many
critical top-level functions that you must learn in addition to the object’s obvious API.
This also affects chainability, which I’ve always appreciated in Ruby. Rather than
continuing your chain as you go, you have to work backwards to add the function in.
Finally, I do truly appreciate the desire for a class/module level function, for exactly
the reasons outlined above. It certainly does work nice for u packing arrays as in the
example above. And, additionally, it’s likely easier to use with more functional
paradigms.
Is it not possible to allow for both styles?
I am personally a huge fan of the instance method versions of all above (zip, merge, etc).
But I also appreciate the class/function styles too.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101383
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
22 Jan
22 Jan
10:23 a.m.
New subject: [ruby-core:111969] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
I believe quite many people are in favor of
`Array.product` and/or `Array.zip`. I wish the implementation/existence of
`Enumerator.product` will work as a pressure towards implementing these methods as well.
I can empathize with that, but there are two important things to consider:
1. Even if standalone `product` is a thing, `Enumerable#product` still needs to be
defined: as my examples show, "first argument is special" is frequent; and
inability to just convert `ary.product(others)` to `ary.lazy.product(others)` is
irritating
2. **If** there would be a course to have a few "standalone methods", I believe
it should be discussed as soon as possible to settle on an acceptable approaches. We have
a small window of opportunity (while `Enumerator.product` is just introduced and can be
considered not creating a lot of backward compatibility issues) to settle on the proper
design. In particular, questions to consider:
* Would standalone methods really be a thing (even if in distant future), or would it
always be just one sore exception?
* If it would be a thing, what would be the proper place for it? Because, actually
**even** for standalone method I don't believe `Enumerator` is the most appropriate.
If it would be in Array, it probably make sense to have a pair of `Array#zip` and
`Array.zip`; probably the same is true for abstract enumerables: `Enumerable#product` and
`Enumerable.product`.
* Other currently existing `Enumerator` class methods (`.new` and `.produce`) are focused
on "creating **a new enumerator** (from some arguments/algorithms)", while
`Enumerator.product` is focused on "apply this operation **to enumerables**"
(producing... whatever it will produce, the user isn't focused on
"enumerator" concept here)
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101400
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
7:07 p.m.
New subject: [ruby-core:111978] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by duerst (Martin Dürst).
Thinking about this a bit more, I guess both the "first argument is special" (A)
and the "all arguments are the same" (B) have use cases. There's probably a
third one, which is "all arguments are already in an array" (C). (B) and (C) are
only one splat/[] away from each other; (A) is clearly a bit farther off from the other
two, see `array_of_arrays.first.product(*array_of_arrays.drop(1))` above.
Making a distinction by using the difference between method with receiver and class method
is one way to accommodate these use cases, but I think it would be more Ruby-like if
receivers where used in both cases and the distinction were made by method name. So as an
example, we could have: `a.zip(b, c)` and `[a,b,c].multi_zip`. `multi_zip` here is only
one possible name, there may be better ones. This solution would allow method chaining,
which is important for good Ruby style.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101415
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
23 Jan
23 Jan
5:54 a.m.
New subject: [ruby-core:111989] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
Just to add a few points:
1. I don't believe "zip with all arguments the same" has really any
significant usage: at least, in codebases I looked in (Ruby stdlib, Rails, Rubocop,
Sidekiq, my work apps) I can't find any. BTW, the trivial case of "have array of
arrays, and want to zip each row" is just `Array#transpose`
2. From the top of my head, I can't think of more methods like `product` and `zip`
(that process uniformly array of arguments, and wouldn't be the same as
`arguments.reduce(:method)`, like `Hash#merge` is), which, considering (1), seems to leave
`product` as a rare special case, not a useful trend to start;
3. In modern Ruby, chainable `product` is trivially implemented: `arys.then { |first,
*rest| first.product(*rest) }`. If, by chance, [anonymous params for
blocks](https://bugs.ruby-lang.org/issues/19370) would become a thing, it would even be
`arys.then { |first, *| first.product(*) }`. It might still look worse than one
specialized method, though.
4. Oh, and returning to `zip`, its first argument **is** special, because it defines the
size of the output:
```ruby
%w[a b c].zip([1, 2], %i[x])
# => [["a", 1, :x], ["b", 2, nil], ["c", nil, nil]]
[1, 2].zip(%w[a b c], %i[x])
# => [[1, "a", :x], [2, "b", nil]]
%i[x].zip(%w[a b c], [1, 2])
# => [[:x, "a", 1]]
```
...so, considering first argument as an "owner" of the operation has its
semantical meaning.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101426
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
9 Feb
9 Feb
11:12 a.m.
New subject: [ruby-core:112305] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by knu (Akinori MUSHA).
Array#product has been there for years and is used a lot. What are the steps to introduce
Enumerable#product without bringing confusion?
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101744
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
11:15 a.m.
New subject: [ruby-core:112306] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
@knu Sorry, I might miss some context.
What's the problem with just straightforwardly introducing `Enumerable#product` (which
would be redefined in `Array`), the same as it is with many other `Enumerable` methods?..
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-101745
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
7 Nov
7 Nov
7:47 p.m.
New subject: [ruby-core:115298] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by mame (Yusuke Endoh).
Discussed at the dev meeting. @knu will respond, but I'll give you just an overview of
the discussion.
* We do not remove `Enumerator.product`.
* We may add `Enumerable#product` that returns an Array (not an Enumerator)
* because returning a non-Array is incompatible with existing `Array#product`.
* also because Enumerable methods usually returns an Array.
* If so, we will introduce `Enumerable::Lazy#product` too.
* You will be able to use `.lazy` to get an Enumerator of product.
```
[1, 2].product([3, 4]) #=> [[1, 3], [1, 4], [2, 3], [2, 4]]
[1, 2].to_enum.product([3, 4]) #=> [[1, 3], [1, 4], [2, 3], [2, 4]]
[1, 2].lazy.product([3, 4]) #=> #<Enumerator::Lazy ... >
[1, 2].lazy.product([3, 4]).eager #=> #<Enumerator ... >
[1, 2].lazy.product([3, 4]).force #=> [[1, 3], [1, 4], [2, 3], [2, 4]]
```
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105216
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
6 Dec
6 Dec
11:33 p.m.
New subject: [ruby-core:115621] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by knu (Akinori MUSHA).
We agreed that it's okay to add Enumerable#product that returns an array (of arrays)
and the lazy counterpart Enumerable::Lazy#product.
Do you already have an implementation? Do you want me to do it?
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105553
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
11:33 p.m.
New subject: [ruby-core:115622] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by knu (Akinori MUSHA).
Assignee set to knu (Akinori MUSHA)
Target version set to 3.3
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105554
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: knu (Akinori MUSHA)
* Target version: 3.3
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
15 Dec
15 Dec
4:26 p.m.
New subject: [ruby-core:115758] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
@knu Sorry for the late reply.
I don't have an implementation unfortunately. If it is possible for you to do it, it
would be awesome.
Otherwise, I'll try to do it myself (unless it isn't too late).
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105696
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: knu (Akinori MUSHA)
* Target version: 3.3
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
23 Dec
23 Dec
9:13 a.m.
New subject: [ruby-core:115877] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by knu (Akinori MUSHA).
I couldn't take the time to work on this, sorry.
One thing I noticed while I was thinking of this was that Array#product only takes arrays
and is optimized for iterating over arrays using index access instead of calling `each`.
When we "promote" it to Enumerable#product that takes any enumerables, we'll
probably need to incorporate the optimization into Enumerator::Product to avoid any
performance degradation, where it should check if `each` is redefined.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105834
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: knu (Akinori MUSHA)
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
9:21 a.m.
New subject: [ruby-core:115878] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
Issue #19324 has been updated by zverok (Victor Shepelev).
I couldn't take the time to work on this, sorry.
Yeah, same :(
It seems this has to wait till 3.4 (especially considering the need to think about
optimizations), I'll work on this in January, hopefully.
Sorry, I had a peculiar year, so the changes I proposed at the beginning of it weren't
in my focus during most of it.
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324#change-105835
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: knu (Akinori MUSHA)
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I
find `Enumerator.product` quite confusing, and can't find any justification in
#18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the
expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method
is not as popular (yet?) as I hoped, but still, two methods that do completely different
things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse
them unless you did a lot of math and "product" is firmly set for set product in
your head).
I believe that EITHER of two problems would be concerning enough, but the combination of
them seems to be a strong enough argument to make the change?.. (Maybe with graceful
deprecation of module method in one next version, but, considering the Ruby 3.2 is just
released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
138
days inactive
487
days old
17 comments
6 participants
participants (6)
-
duerst -
knu (Akinori MUSHA)
-
mame (Yusuke Endoh)
-
sawa (Tsuyoshi Sawada)
-
ttilberg (Tim Tilberg)
-
zverok (Victor Shepelev)