[ruby-core:44202] [ruby-trunk - Feature #5632] Attempt to open included class shades it instead.

Issue #5632 has been updated by matz (Yukihiro Matsumoto).

Assignee changed from matz (Yukihiro Matsumoto) to mame (Yusuke Endoh)
Target version set to 3.0

Quite reasonable. But the change would introduce serious incompatibility, so that we can not make this happen in 2.0.

Matz.

----------------------------------------
Feature #5632: Attempt to open included class shades it instead.
https://bugs.ruby-lang.org/issues/5632#change-25729

Author: boris_stitnicky (Boris Stitnicky)
Status: Assigned
Priority: Normal
Assignee: mame (Yusuke Endoh)
Category: 
Target version: 3.0


# Hello everyone. I'm not a very advanced ruby user, and I
# would like to provide and outsider report on certain ruby
# behavior that might surprise newbies.

module A
  class X
    def hello; puts 'hello' end
  end
end

module B
  include A
end

B::X.new.hello
=> hello
# As expected.

# But when I tried to add new functionality to X, ...
module B
  class X
    def goodbye; puts 'goodbye' end
  end
end

B::X.new.hello
=> NoMethodError

# I was surprised, that my .hello method disappeared,
# when all I was trying to do, was to improve X in B.
# I actually somehow expected to work on a subclass
# of X, like this:

module C
  include A
  class X < X
    def goodbye; puts 'goodbye' end
  end
end

# My suggestions are:
# 1. I consider 'class X < X' syntax a little bit
#    mysterious. How about making this a default
#    behavior for 'class X' statements?
# 2. If the above is not considered beneficial, I
#    would welcome if 'class X' statement warned
#    when shadowing an existing name. People might
#    often assume that they are opening an existing
#    class, rather than getting a brand new one
#    shadowing the previous one. If people really
#    want a brand new shadowing class without warning
#    they could use explicit 'X = Class.new'.


-- 
http://bugs.ruby-lang.org/