https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-06-14T05:58:20ZRuby Issue Tracking SystemRuby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=861572020-06-14T05:58:20Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/86157/diff?detail_id=57341">diff</a>)</li></ul> Ruby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=861602020-06-14T10:32:49ZEregon (Benoit Daloze)
<ul></ul><p>Could MJIT add its own check if called on a Fixnum, then do the inline fast-path logic, otherwise fallback to a call to the original definition?<br>
One would still need to check that Numeric#zero? is not redefined, but in all cases it's needed to check if redefined (whether it's Numeric#zero? or Integer#zero?).<br>
That would work transparently without adding a new method.</p>
<p>Somewhat similar logic in TruffleRuby for <code>+</code>, <code>nil?</code>, etc, handling a subset of inputs, and rewriting as a call if inputs don't match that:<br>
<a href="https://github.com/oracle/truffleruby/tree/17701a09fca2fa1641353582d8c7be8216345b8a/src/main/java/org/truffleruby/core/inlined" class="external">https://github.com/oracle/truffleruby/tree/17701a09fca2fa1641353582d8c7be8216345b8a/src/main/java/org/truffleruby/core/inlined</a></p>
<p>I think we should avoid many new methods on e.g. Integer/Array duplicating Numeric/Enumerable, but rather have generic tricks to be able to specialize on common cases.</p> Ruby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=861652020-06-14T21:32:33Zmarcandre (Marc-Andre Lafortune)marcandre-ruby-core@marc-andre.ca
<ul></ul><p>I imagine that it is fine as long as it's not done in a patch release and it appears in the <code>NEWS</code>.</p>
<p><code>Array</code> has had some methods specialized for optimization purposes (<code>minmax</code> in 2.7, <code>min/max/sum</code> in 2.4, ...)</p>
<p>I doubt there are many valid reasons to redefine <code>Numeric#zero?</code> such that <code>Integer#zero?</code> wouldn't behave as expected.</p> Ruby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=861662020-06-14T21:39:40Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><blockquote>
<p>Could MJIT add its own check if called on a Fixnum</p>
</blockquote>
<p>You're right, that thing is <em>technically</em> not difficult. What I'm trying to do is to avoid adding MJIT-only method definition (like fast-path logic used only for MJIT) or (#ifdef) branches so that we do not cause bugs by discrepancy between VM and JIT and we do not need to maintain lots of copy-pasted code for MJIT.</p>
<blockquote>
<p>I think we should avoid many new methods on e.g. Integer/Array duplicating Numeric/Enumerable</p>
</blockquote>
<p>My assumption is that we already have many methods on <code>Integer</code> rather than <code>Numeric</code>, and this discussion is for minor leftovers which are inconsistent with other major methods. When such Numeric methods have branches for Integer, Complex, and Rational, removing a branch for Integer from Numeric and adding it as an Integer method don't cause a lot of code duplication at least.</p>
<blockquote>
<p>rather have generic tricks to be able to specialize on common cases.</p>
</blockquote>
<p>That'd be nice, but because I've already spent a lot of time for considering options I can easily think of, please describe your idea with concrete interface which is used to maintain it.</p>
<p>What kind of code in numeric.c or numeric.rb do you imagine to write for having Integer fast path for <code>num_zero_p</code>? Doesn't it create a path or code duplication which is never used (or tested) on VM? If not, doesn't it complicate the original method definition? (Well, I'm not saying we should never do such things, but those are what I tried to maintain when choosing the current proposal.)</p>
<p>Another idea brought by ko1 in case overriding it is considered a breaking change is that we undef <code>Integer#zero?</code> when <code>Numeric#zero?</code> is redefined. That's another vector for complication, but at least this technique could be also useful for VM and it's not too MJIT-specific.</p> Ruby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=862252020-06-18T08:49:15Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>We already have those overriding methods (e.g. Enumerable and Array) for performance. So I think it's OK if there's a clear benefit.</p>
<p>Matz.</p> Ruby master - Misc #16961: Is overriding a method in a subclass considered as a breaking change or not?https://bugs.ruby-lang.org/issues/16961?journal_id=862472020-06-18T18:07:13Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul>