https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112012-12-01T09:13:30ZRuby Issue Tracking SystemRuby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342572012-12-01T09:13:30Ztrans (Thomas Sawyer)
<ul></ul><p>Here is a slightly more updated version of the RCR: <a href="https://github.com/rubyworks/cuts/blob/master/RCR.textile" class="external">https://github.com/rubyworks/cuts/blob/master/RCR.textile</a></p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342592012-12-01T09:55:25Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul><li><strong>Priority</strong> changed from <i>6</i> to <i>Normal</i></li><li><strong>Target version</strong> changed from <i>2.0.0</i> to <i>2.6</i></li></ul><p>Sorry, cuts are too late for ruby 2.0.0. We started feature freeze last month.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342622012-12-01T13:31:31Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Target version</strong> changed from <i>2.6</i> to <i>3.0</i></li></ul><p>And it's too big to next minor.</p>
<p>Matz.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342772012-12-01T22:19:45Ztrans (Thomas Sawyer)
<ul></ul><p>This is too big, but refinements aren't?</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342812012-12-02T00:29:58Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Because we have made decision fore refinement before freeze.</p>
<p>Matz.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342822012-12-02T00:40:06Ztrans (Thomas Sawyer)
<ul></ul><p>I didn't understand such response at first. Now, I think I realize possible confusion. I am proposing that cuts be used as underlying implementation for refinements. The whole <code>cut A < C</code> construct does not need to be exposed --it is nothing that end developer's would even see at this point. The point is to give refinements a well grounded design framework.</p>
<p>As they currently stand refinements look like an arbitrarily implemented kludge. I don't think anyone in their right mind would go near them. And I fear they will severely hamper adoption of Ruby 2.0.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342832012-12-02T00:53:27ZThe8472 (Aaron G)the8472@infinite-source.de
<ul></ul><p>On 01.12.2012 16:40, trans (Thomas Sawyer) wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Cutting through the issues with Refinements (Rejected)" href="https://redmine.ruby-lang.org/issues/7487">#7487</a> has been updated by trans (Thomas Sawyer).</p>
<p>I didn't understand such response at first. Now, I think I realize possible confusion. I am proposing that cuts be used as underlying implementation for refinements. The whole <code>cut A < C</code> construct does not have to be exposed --It is nothing that end developer's would even see at this point. The point is to give refinements a well grounded design framework.</p>
</blockquote>
<p>Ah, I missed this this thread and proposed something very similar (AST<br>
transforms) to achieve pretty much the same thing in the other one, see<br>
<a href="https://bugs.ruby-lang.org/issues/4085#note-211" class="external">https://bugs.ruby-lang.org/issues/4085#note-211</a> (sorry for cross-posting)</p>
<p>That would be a more ruby-esque API on which refinements could be built.</p>
<blockquote>
<p>As they currently stand refinements look like an arbitrarily implemented kludge. I don't think anyone in there right mind would go near them. And I fear they would severely hamper adoption of Ruby 2.0.</p>
</blockquote>
<p>I agree. We need a proper solution that integrates with the rest of the<br>
language.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342862012-12-02T01:23:15ZAnonymous
<ul></ul><p>In message "Re: <a href="/issues/7487">[ruby-core:50448]</a> [ruby-trunk - Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Cutting through the issues with Refinements (Rejected)" href="https://redmine.ruby-lang.org/issues/7487">#7487</a>] Cutting through the issues with Refinements"<br>
on Sun, 2 Dec 2012 00:40:07 +0900, "trans (Thomas Sawyer)" <a href="mailto:transfire@gmail.com" class="email">transfire@gmail.com</a> writes:</p>
<p>|I didn't understand such response at first. Now, I think I realize possible confusion. I am proposing that cuts be used as underlying implementation for refinements. The whole <code>cut A < C</code> construct does not have to be exposed --It is nothing that end developer's would even see at this point. The point is to give refinements a well grounded design framework.</p>
<p>I am not sure if I understand you correctly. If it's not exposed to<br>
end users, how should it be seen by refinement implementers?</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342912012-12-02T02:39:13Ztrans (Thomas Sawyer)
<ul></ul><p>Same way as you have it now. The difference is behind the scenes.</p>
<p>module M<br>
refine String do<br>
def foo; "foo"; end<br>
end<br>
end</p>
<p>Under the hood this would create the equivalent of:</p>
<p>cut M::Refinements::String < String<br>
def self.apply?(s)<br>
s.include_refinement?(self)<br>
end<br>
def foo; "foo"; end<br>
end</p>
<p>The name "M::Refinements::String" is arbitrary. Under the hood it doesn't even have to have a defined constant (though it might be helpful to have such a handle on it).</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=342922012-12-02T03:00:37Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Probably I don't understand your true intention, but your proposal includes new syntax with new keyword, we cannot add it by 2.0. Besides that, there's no way to optimize 'cut' in compile-time, if I understand it correctly.</p>
<p>Matz.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=344062012-12-05T18:56:50Ztrans (Thomas Sawyer)
<ul></ul><p>Well, that's is what I meant by "under the hood". There would be no new keyword exposed to Ruby and cuts could only be created via C code, at least until new major version. But, it doesn't matter anyway. <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/286">@headius (Charles Nutter)</a> has made clear to me what you actually intend refinements to be (i.e. so called "method decorators"). This is not the same as cuts, which are a means of injecting/changing actual behavior of classes.</p>
<p>Cuts are still a powerful abstraction with plenty uses, but not as a means of implementing refinements. So I will have this issue closed and revisit cuts again at a later date.</p> Ruby master - Feature #7487: Cutting through the issues with Refinementshttps://redmine.ruby-lang.org/issues/7487?journal_id=344102012-12-05T20:57:00Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>OK, try again some time later.</p>
<p>Matz.</p>