[#71815] [Ruby trunk - Bug #11768] [Open] Add a polymorphic inline cache — tenderlove@...
Issue #11768 has been reported by Aaron Patterson.
tenderlove@ruby-lang.org wrote:
On Thu, Dec 03, 2015 at 10:51:08PM +0000, Eric Wong wrote:
Aaron Patterson <tenderlove@ruby-lang.org> wrote:
[#71818] [Ruby trunk - Feature #11769] [Open] optimize case / when for `nil` — tenderlove@...
Issue #11769 has been reported by Aaron Patterson.
tenderlove@ruby-lang.org wrote:
[#71931] [Ruby trunk - Feature #11786] [Open] [PATCH] micro-optimize case dispatch even harder — normalperson@...
Issue #11786 has been reported by Eric Wong.
Oops, I forgot to free the table when iseq is destroyed :x
On 2015/12/08 12:43, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2015/12/08 13:53, Eric Wong wrote:
[#72028] [Ruby trunk - Feature #11405] [Assigned] [PATCH] hash.c: minor speedups to int/fixnum keys — mame@...
Issue #11405 has been updated by Yusuke Endoh.
mame@ruby-lang.org wrote:
[#72045] Ruby 2.3.0-preview2 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 2.3.0-preview2.
Please add your optimizations before RC1.
SASADA Koichi <ko1@atdot.net> wrote:
On 2015/12/11 18:06, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#72069] [Ruby trunk - Feature #11405] [PATCH] hash.c: minor speedups to int/fixnum keys — mame@...
Issue #11405 has been updated by Yusuke Endoh.
[#72115] Re: [ruby-cvs:60264] duerst:r53112 (trunk): * enc/ebcdic.h: new dummy encoding EBCDIC-US — "U.NAKAMURA" <usa@...>
Hi,
On 2015/12/14 22:34, U.NAKAMURA wrote:
Hi,
[ruby-core:72004] [Ruby trunk - Bug #11779] Module#using does not make sense as a method
Issue #11779 has been updated by bug hit.
Shugo Maeda wrote:
> bug hit wrote:
> > > Nobu didn't explain that Module#using should work in methods.
> > > Module#using is designed not for such dynamic use.
> >
> > Note that when #using is called in a module_eval block, its effect is confined to the body of the block. So why should it matter if module_eval is called from a method or top level or from another module/class? ~~Regardless of where it's called, #using inside it works the same.~~ The call site does not influence what #using does nor is influenced by it.
>
> Because refinement activation should be as static as possible.
> It might be better to prohibit Module#using in module_eval.
Perhaps, since you can apply the refinement outside the module_eval block which will also affect the block:
```ruby
module Refinement
refine String do
def refined?
true
end
end
end
module Foo
end
module Bar
using Refinement
Foo.module_eval do
p((''.refined? rescue false))
end
end
```
so a #using in module_eval is only useful if you want the refinement confined to the block. There might be uses for that, not sure.
But if this functionality remains, it should work wherever module_eval is invoked.
----------------------------------------
Bug #11779: Module#using does not make sense as a method
https://bugs.ruby-lang.org/issues/11779#change-55413
* Author: bug hit
* Status: Feedback
* Priority: Normal
* Assignee:
* ruby -v: 2.2.3
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
1. it can't be called from another method
2. the receiver must be self
3. since refinements are lexically scoped the self receiver must match the currently open class
#3 is particularly curious
```ruby
module Refinement
refine String do
def refined?
true
end
end
end
module Foo
def self.refined?
''.refined? rescue false
end
end
module Bar
def self.refined?
''.refined? rescue false
end
Foo.module_eval do
using Refinement
end
end
p Foo.refined? #false
```
The module_eval `#using` call does not raise (it's not from a method and the receiver is self), but evidently because currently open class does not match self, it does not do anything. So it should at least raise.
So `#using`, though a method, does not function as a method, which is misleading.
--
https://bugs.ruby-lang.org/