https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112017-05-28T08:29:08ZRuby Issue Tracking SystemRuby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651382017-05-28T08:29:08Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>Sounds interesting in theory, but do you have actual use cases? And do you think that the potential inefficiency is worth it?</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651402017-05-28T14:01:21Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I am not even sure that I understand the proposal.</p>
<p>If I understood it correctly then two enumerable objects (did I get this part right)<br>
should return true if they behave/return the same? I think I can see it being<br>
related to duck typing... but they are not entirely the same are they? Different<br>
object id for most objects for example. But it also may be that I did not fully<br>
understand the proposal yet.</p>
<p>What would the speed penalty be if one exists? I guess the latter one could be<br>
handled by some "behavioural switch" for people who need the behaviour<br>
desscribed in the proposal, so a use-case example would be helpful.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651412017-05-28T16:50:31Zglebm (Gleb Mazovetskiy)
<ul></ul><p>shevegen (Robert A. Heiler) wrote:</p>
<blockquote>
<p>[...] but they are not entirely the same are they? Different<br>
object id for most objects for example. But it also may be that I did not fully<br>
understand the proposal yet.</p>
</blockquote>
<p>Most objects in Ruby are compared semantically if the object IDs are different, including <code>Array</code> and <code>Hash</code>.</p>
<blockquote>
<p>What would the speed penalty be if one exists?</p>
</blockquote>
<p>If the <code>Enumerator</code>s have different <code>object_id</code>s, previous the equality check was <code>O(1)</code> but is <code>O(n)</code> with this proposal (just like for <code>Array</code>).</p>
<blockquote>
<p>I guess the latter one could be<br>
handled by some "behavioural switch" for people who need the behaviour<br>
desscribed in the proposal, so a use-case example would be helpful.</p>
</blockquote>
<p>I am not proposing a behavioural switch. This should be a backwards-incompatible change.<br>
Use cases are the same as for arrays, except when the "arrays" are "lazy".</p>
<p>Example:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">].</span><span class="nf">reverse</span> <span class="o">==</span> <span class="p">[</span><span class="mi">3</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">1</span><span class="p">]</span>
<span class="c1">#=> true</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">].</span><span class="nf">reverse_each</span> <span class="o">==</span> <span class="p">[</span><span class="mi">3</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">1</span><span class="p">]</span>
<span class="c1">#=> false</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">].</span><span class="nf">reverse_each</span> <span class="o">==</span> <span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">].</span><span class="nf">reverse_each</span>
<span class="c1">#=> false</span>
</code></pre>
<p>With this proposal, the last two are also <code>true</code>.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651422017-05-28T16:55:14Zglebm (Gleb Mazovetskiy)
<ul></ul><p>duerst (Martin Dürst) wrote:</p>
<blockquote>
<p>Sounds interesting in theory, but do you have actual use cases? And do you think that the potential inefficiency is worth it?</p>
</blockquote>
<p>The use cases are the same as for comparing <code>Array</code>s.<br>
The potential inefficiency is not a problem because if you need to compare <code>Enumerator</code>s by <code>object_id</code> you can do it using <code>equal?</code>. If the <code>object_id</code>s are the same, both the current and the proposed comparisons take constant time.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651432017-05-28T18:21:51ZMSP-Greg (Greg L)
<ul></ul><p>Could be helpful, but some <code>Enumerators</code> are not ordered. So how would <code>==</code> work for 'hash like' objects (assuming they're not based on a hash, which has an <code>==</code> operator)?</p>
<p>I suppose it could be considered 'restricted' to ordered collections...</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651452017-05-28T19:48:57Zglebm (Gleb Mazovetskiy)
<ul></ul><p>MSP-Greg (Greg L) wrote:</p>
<blockquote>
<p>Could be helpful, but some <code>Enumerators</code> are not ordered. So how would <code>==</code> work for 'hash like' objects (assuming they're not based on a hash, which has an <code>==</code> operator)?</p>
<p>I suppose it could be considered 'restricted' to ordered collections...</p>
</blockquote>
<p>Equal objects should produce equal results when used.<br>
From this perspective on equality, enumerators that yield in different order should not be considered equal, even if they internally yield elements from an unordered collection.</p>
<p>If the enumerator yields in a different order every time it's called, then the comparison is not guaranteed to return the same result every time. This is a rare edge case though.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651502017-05-29T07:13:26Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>MSP-Greg (Greg L) wrote:</p>
<blockquote>
<p>Could be helpful, but some <code>Enumerators</code> are not ordered.</p>
</blockquote>
<p>All <code>Enumerators</code> are ordered. The order is defined by the <code>each</code> method, or alternatively by the <code>to_a</code> method.</p>
<p>Actually, I wonder if there's any difference between what the OP wants and</p>
<pre><code>enumerator_A.to_a == enumerator_B.to_a
</code></pre>
<p>Although direct comparison for equality would be shorter, the above makes it explicit that efficiency may be low.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=651552017-05-29T14:50:46Zglebm (Gleb Mazovetskiy)
<ul></ul><p>duerst (Martin Dürst) wrote:</p>
<blockquote>
<p>Actually, I wonder if there's any difference between what the OP wants and</p>
<pre><code>enumerator_A.to_a == enumerator_B.to_a
</code></pre>
</blockquote>
<p>The above allocates Arrays, Enumerator equality would not.</p> Ruby master - Feature #13606: Enumerator equality and comparisonhttps://redmine.ruby-lang.org/issues/13606?journal_id=663872017-08-31T07:36:01Zknu (Akinori MUSHA)knu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Rejected</i></li></ul><p>Without any actual use case, there would be no effective definition of equality for enumerators.</p>
<p>FWIW, the initial design policy is, Enumerator is an abstract entity that only guarantees it responds to <code>each</code> for enumeration, and it's not your problem as to what's behind a given enumerator. You shouldn't have to care about the equality in the first place.</p>