[#38647] [Ruby 1.9 - Bug #5130][Open] Thread.pass sticks on OpenBSD — Yui NARUSE <naruse@...>

16 messages 2011/08/01

[#38653] [Ruby 1.9 - Bug #5135][Open] Ruby 1.9.3-preview1 tests fails in Fedora Rawhide — Vit Ondruch <v.ondruch@...>

31 messages 2011/08/01

[#38666] [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Yehuda Katz <wycats@...>

61 messages 2011/08/01
[#38667] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Aaron Patterson <aaron@...> 2011/08/01

On Tue, Aug 02, 2011 at 07:35:15AM +0900, Yehuda Katz wrote:

[#38669] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Urabe Shyouhei <shyouhei@...> 2011/08/01

(08/02/2011 07:46 AM), Aaron Patterson wrote:

[#38671] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Eric Wong <normalperson@...> 2011/08/01

Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#38695] [Ruby 1.9 - Bug #5144][Open] Remove GPL file from repository — Vit Ondruch <v.ondruch@...>

17 messages 2011/08/02

[#38706] [Ruby 1.9 - Bug #5147][Open] mkmf should not require static library when ruby is built with --enable-shared — Vit Ondruch <v.ondruch@...>

9 messages 2011/08/02

[#38894] Why Ruby has versioned paths? — V咜 Ondruch <v.ondruch@...>

Hello, could somebody please elaborate about reasons why Ruby uses versioned

9 messages 2011/08/10

[#38972] [Ruby 1.9 - Bug #5193][Open] ruby_thread_data_type linker errors fixed with RUBY_EXTERN — Charlie Savage <cfis@...>

28 messages 2011/08/16

[#38980] :symbol.is_a?(String) — Magnus Holm <judofyr@...>

http://viewsourcecode.org/why/redhanded/inspect/SymbolIs_aString.html

8 messages 2011/08/16

[#39025] [Ruby 1.9 - Feature #5206][Open] ruby -K should warn — Eric Hodel <drbrain@...7.net>

14 messages 2011/08/19

[#39062] Releasing r33028 as Ruby 1.9.3 RC1 — Yugui <yugui@...>

Hi,

17 messages 2011/08/23

[#39093] [Ruby 1.9 - Bug #5227][Open] Float#round fails on corner cases — Marc-Andre Lafortune <ruby-core@...>

14 messages 2011/08/24
[#39115] [Ruby 1.9 - Bug #5227][Assigned] Float#round fails on corner cases — Yui NARUSE <naruse@...> 2011/08/26

[#39126] Re: [Ruby 1.9 - Bug #5227][Assigned] Float#round fails on corner cases — Marc-Andre Lafortune <ruby-core-mailing-list@...> 2011/08/26

Hi

[#39120] [Ruby 1.9 - Bug #5233][Open] OpenSSL::SSL::SSLSocket has problems with encodings other than "ascii" — Niklas Baumstark <niklas.baumstark@...>

9 messages 2011/08/26

[#39142] [Ruby 1.9 - Bug #5239][Open] bootstraptest/runner.rb: assert_normal_exit logic broken on Debian/GNU kFreeBSD — Lucas Nussbaum <lucas@...>

11 messages 2011/08/27

[#39162] [Ruby 1.9 - Bug #5244][Open] Continuation causes Bus Error on Debian sparc — Lucas Nussbaum <lucas@...>

29 messages 2011/08/28

[ruby-core:38826] Re: [Ruby 1.9 - Bug #5148][Open] Constant Namespace/Scoping in Dynamic Classes/Modules

From: Benoit Daloze <eregontp@...>
Date: 2011-08-06 18:24:26 UTC
List: ruby-core #38826
Hi,
On 2 August 2011 17:01, Thomas Sawyer <transfire@gmail.com> wrote:
> Bug #5148: Constant Namespace/Scoping in Dynamic Classes/Modules
> http://redmine.ruby-lang.org/issues/5148
>
> When defining a dynamic class or module, the constants defined within it are not kept within it's namespace, but are tied to the outer scope's namespace.
>
>  = Class.new do
> odule M; end
> nd
> => #<Class:0xa601300>
> ::M => M
>  #=> M

I also noticed that recently.
It seems inconsistent to me.
Let's have some code:
https://gist.github.com/1129567

Constant scoping seems to depend on the the fact it is defined in a
"dynamic" scope or not.
But one can force to define on a specific scope by doing scope::Const
= value (like self::C = value in a Class.new block).

I think the constant definition scope should always be the current
scope (as you would always add "self::" before the constant name).
Also, this should be true for constant resolution, I should not need
self.class::CONST, in a parent class to resolve a child class's
constant.

To "solve" your problem, you could use self::

describe "unfancy mixin" do
  class self::Foo # not at toplevel
    include UnfancyMixin
  end
  # Foo # uninitialized constant Foo (NameError)
  self::Foo # => #<Class:0x00000100857ba8>::Foo
  const_get :Foo # => #<Class:0x00000100857ba8>::Foo
end

But it has an immediate pitfall: you can not reference it by 'Foo',
you need 'self::Foo' or 'const_get :Foo'.

Variables and method calls are fully dynamic for
definition/resolution, in opposition to constants.

Can someone explain the rationale behind this logic ?

In This Thread