[#79914] [Ruby trunk Bug#13282] opt_str_freeze does not always dedupe — normalperson@...
Issue #13282 has been reported by Eric Wong.
4 messages
2017/03/05
[#80140] [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus) — shyouhei@...
Issue #13295 has been updated by shyouhei (Shyouhei Urabe).
5 messages
2017/03/13
[#80362] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— Eric Wong <normalperson@...>
2017/03/26
shyouhei@ruby-lang.org wrote:
[#80368] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— SASADA Koichi <ko1@...>
2017/03/27
On 2017/03/26 15:16, Eric Wong wrote:
[#80205] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint — Eric Wong <normalperson@...>
duerst@ruby-lang.org wrote:
4 messages
2017/03/17
[#80213] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint
— Martin J. Dürst <duerst@...>
2017/03/17
Hello Eric,
[#80290] [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch — normalperson@...
Issue #13355 has been reported by normalperson (Eric Wong).
4 messages
2017/03/23
[#80410] Re: [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch
— Eric Wong <normalperson@...>
2017/03/27
normalperson@yhbt.net wrote:
[#80415] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
5 messages
2017/03/28
[#80488] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
4 messages
2017/03/29
[ruby-core:80195] [Ruby trunk Bug#13271] Clarifications on refinement spec
From:
shugo@...
Date:
2017-03-17 00:35:36 UTC
List:
ruby-core #80195
Issue #13271 has been updated by shugo (Shugo Maeda).
Gondolin (Damien Robert) wrote:
> shugo (Shugo Maeda) wrote:
> > The behavior was changed by Feature #8571.
>
> Well I prefer that this feature remains so that's nice! But this probably means that the spec should be updated then?
Yes. I'll update doc/syntax/refinements.rdoc after investigating 2) further.
----------------------------------------
Bug #13271: Clarifications on refinement spec
https://bugs.ruby-lang.org/issues/13271#change-63634
* Author: Gondolin (Damien Robert)
* Status: Assigned
* Priority: Normal
* Assignee: shugo (Shugo Maeda)
* Target version:
* ruby -v: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
Consider the following code:
~~~ruby
class Foo
def foo
"Foo#foo"
end
def bar
"Foo#bar"
end
end
class Bar < Foo
def foo
"Bar#foo -> "+super
end
def bar
"Bar#bar -> "+super
end
end
module R1
def foo
"R1#foo -> "+super
end
def bar
"R1#bar -> "+super
end
end
module R2
def foo
"R2#foo -> "+super
end
def bar
"R2#bar -> "+super
end
end
module M2
refine Foo do
include R2
def foo
"refinement:Foo@M2#foo -> "+super
end
def bar
"refinement:Foo@M2#bar -> "+super
end
end
end
module M1
include M2
refine Foo do
include R1
def foo
"refinement:Foo@M1#foo -> "+super
end
end
end
using M1
puts Foo.new.foo #refinement:Foo@M1#foo -> R1#foo -> Foo#foo
puts Foo.new.bar #R1#bar -> refinement:Foo@M2#bar -> R2#bar -> Foo#bar
puts Bar.new.foo #Bar#foo -> Foo#foo
puts Bar.new.bar #Bar#bar -> Foo#bar
~~~
I have several questions about the results.
1) As I was expecting, '`using M1`' not only activate the refinements of `M1` but also the refinements of the included module `M2`.
In other word it behaves as if I had specified '`using M2; using M1`'. This is what I was expecting but from reading the spec
"(3) Activate refinements in the defined refinement table of `mod`" it looks like the spec only speak about the refined modules in `M1`.
2) As noted in the spec, `refinement:Foo@M1` should behave as if its superclass was `Foo`, so the fact that `Foo.new.foo` does not go through the refinements of `M2` was expected.
However I find the result of '`Foo.new.bar`' strange: `refinement:Foo@M1` does not contain the bar method, but its included module `R1` does. So should not the result be
`R1#bar -> Foo#bar`, whithout going through the refinements methods of `M2`?
The spec states "(3) If `C` has included modules, for these modules `M` If a method with name `N` found in the method table of `M`, return the method."
But it does not stipulate what happen if we call super in one of these included method.
3) I am also surprised by the behaviour of `Bar.new.foo` and `Bar.new.bar`. According to the spec:
"(7) If `C` has a direct superclass, search the method `N` as specified in "Normal method lookup" from Step 4, where `C` is the superclass."
and Step 4 start by looking at the activated refinements.
So I was expecting the results to go through `Foo`'s refinement, so that for instance '`Bar.new.foo`' would be
`Bar#foo -> refinement:Foo@M1#foo -> R1#foo -> Foo#foo`
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>