[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
ko1@atdot.net wrote:
Eric Wong <normalperson@yhbt.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2014/10/09 11:04, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
On 2014/10/09 20:41, Xavier Noria wrote:
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, normal@ruby-lang.org wrote:
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
2014-10-16 12:48 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
[ruby-core:65478] [ruby-trunk - Feature #9112] Make module lookup more dynamic (Including modules into a module after it has already been included)
Issue #9112 has been updated by Timur Duehr.
I'm working on a patch for this to use a live tree for module ancestry. I had already implemented this as part of Module#prepend before coming across this discussion. I wrote a test for this behavior as a starting point but it fails under the current behavior.
~~~
m = Module.new
m.module_eval do
def foo; :foo; end
end
class << m; self; end.class_eval do
define_method(:included) {|mod| raise }
end
m2 = Module.new
assert_raise(RuntimeError) do
m2.module_eval { include(m) }
end
m3 = Module.new
assert_raise(RuntimeError) do
m3.module_eval { include(m2) }
end
~~~
`m.included` is only called on the include for `m2` not `m3`.
Other than wrapping methods, which would be seen by includes further down the chain in either the current or live ancestries, I can't think of an example of hierarchy changes that would fire when including `m2` into `m3`. Do you have an example of one such action?
----------------------------------------
Feature #9112: Make module lookup more dynamic (Including modules into a module after it has already been included)
https://bugs.ruby-lang.org/issues/9112#change-49258
* Author: Tobias Pfeiffer
* Status: Assigned
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version:
----------------------------------------
If a module (M) is included into a class (C) and afterwards another module (M2) is included into the first module (M) then C does not include M2 and instances do not respond to methods defined in M2. I think instances of C should respond to methods defined in M2 and C should include M2.
I created a gist detailing the problem I have: https://gist.github.com/PragTob/7472643
I think this behavior is confusing, because if I'd reopen module M and just add methods there then instances of C can call those methods. However if I include another module in M then instances of C can not call those methods.
Any opinions on if this would be a better behavior or why it isn't?
(was unsure to file it as a bug or feature)
--
https://bugs.ruby-lang.org/