From: "ttilberg (Tim Tilberg) via ruby-core" <ruby-core@...>
Date: 2023-01-21T00:48:17+00:00
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/

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/