I think that ruby is a bit too intelligent regarding module names.
Consider the follwing situation
module B
class B; end
end
module A
module B
module C
class C < B::B; end
end
end
end
This does not work, as ruby tries to load A::B instead of B::B as
I supposed. So for example I can't create a class structure
module MyProg
module UI
module Gnome
class Something < Gnome::Canvas
end
end
end
even though this would seem a natural naming scheme to me.
What is the reason behind this behaviour, and is it possible to avoid
this problem without renaming my module to MyProg::UI::GnomeUI which
seems redundant to me?
"Brian Schroeder" <spam0504@bssoftware.de> schrieb im Newsbeitrag
news:pan.2004.08.24.10.58.57.712590@bssoftware.de...
Hello Group,
I think that ruby is a bit too intelligent regarding module names.
No, that's usual scope resolution practice as found in other languages (C++
etc.). Module resolution starts always at the nearest possible position,
which makes perfectly sense since it saves a lot of typing for the usual
case, i.e. when you want to refer to something in a sibling module.
Consider the follwing situation
module B
class B; end
end
module A
module B
module C
class C < B::B; end
As Mr. T already pointed out use the form ::B to explicitely start lookup
from the top level.
end
end
end
This does not work, as ruby tries to load A::B instead of B::B as
I supposed. So for example I can't create a class structure
module MyProg
module UI
module Gnome
class Something < Gnome::Canvas
end
end
end
even though this would seem a natural naming scheme to me.
What is the reason behind this behaviour, and is it possible to avoid
this problem without renaming my module to MyProg::UI::GnomeUI which
seems redundant to me?
As Mr. T already pointed out use the form ::B to explicitely start
lookup from the top level.
Thank you all for the replies. This was a very helpful information. I just never
read that ::Y starts at the top level - so as always it was not ruby too
intelligent, but I missed the important point.