Trans
11/21/2007 2:34:00 AM
On Nov 20, 5:17 pm, "Sean O'Halpin" <sean.ohal...@gmail.com> wrote:
> On Nov 20, 2007 1:53 PM, Trans <transf...@gmail.com> wrote:
>
> > This doesn't seem right to me:
>
> > irb(main):001:0> module X
> > irb(main):002:1> module A; end
> > irb(main):003:1> end
> > => nil
> > irb(main):004:0> class Q
> > irb(main):005:1> include X
> > irb(main):006:1> p A
> > irb(main):007:1> class Y
> > irb(main):008:2> class Z < A
> > irb(main):009:3> end
> > irb(main):010:2> end
> > irb(main):011:1> end
> > X::A
> > NameError: uninitialized constant Q::Y::A
> > from (irb):8
>
> > If I recall correctly, 1.9 has some changes to constant lookup rules.
> > Is the above fixed in 1.9?
>
> > Thanks,
> > T.
>
> Hi Trans,
>
> I'm not sure I understand what you expect. In the following example:
>
> class A
> end
>
> module Outer
> module X
> class A # you meant 'class' didn't you? ;)
Oops. Yes.
> end
> end
>
> class A
> end
>
> class Q
> include X
> class Y
> p A
> class Z < A # which A do you want?
> end
> # this seems reasonable to me...
> class XZ < X::A
> end
> end
> end
> end
>
> which A should Z be a subclass of?
Fair question. I would expect the closest, and in this case it would
be the one defined in X, since that's what is asked for in the
namespace with "include X". The problem with the way it is now is very
much like the problem with XML namespaces. That X::, which seems so
reasonable here turns into Some::Deep::Space:: in real life. And if
we're defining a number of such subclasses (as I am) we have to repeat
it over and over. No fun.
However, I did find a trick.
module X
class A
include X
end
end
This helps once I get past the first subclass (all subsequent
subclasses can see all of X). Weird, huh?
T.