[#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:65508] [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 Yukihiro Matsumoto. The reasons behind the current behavior are as you have guessed. Besides that, it was quite difficult to implement this more dynamic inclusion efficiently (both space-wise and time-wise). So with smarter implementation, with proper timing, I don't reject. But it will not happen in coming 2.2, at least. Matz. ---------------------------------------- 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-49283 * 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/