Csaba Henk
2/21/2005 11:42:00 PM
On 2005-02-21, Trans <transfire@gmail.com> wrote:
>
>> What you get by self.class::C is the desirable behaviour in the 99%
> of
>> cases: thus C is visible from subclasses' instances as well, but can
> be
>> overridden in a subclass. As one would expect in an object oriented
>> environment.
>
> I beleive I agree. I have started to think that the idea of a
> _constant_ has no place in Ruby all together. I say, throw the warning
> about constant redefinition away.
Btw, redefining a constant in a subclass doesn't trigger that warning.
class A
Foo = 5
end
class B < A
Foo = Foo + 1
# Foo +=1 is also OK
end
[A::Foo,B::Foo] # => [5,6]
What happens here is that at its creation B doesn't have Foo defined in
it. Then, when doing "Foo = Foo + 1", ruby first finds out Foo's value
in the initial context (finds that in A), then adds one to it and
defines a fresh new Foo, exclusively for B, with that value. No constant
has been redefined...
What now I'm wondering about is the following: as I see, there is no way to
reflect to the place of a definition of a constant. That is,
class A
Foo=5
end
class B < A
end
[A::Foo, A.constants, class A; self::Foo; end] #=> [5, ["Foo"], 5]
[B::Foo, B.constants, class B; self::Foo; end] #=> [5, ["Foo"], 5]
You'll only see a difference when you try to assign to Foo in A and in
B's context, which does give a reflection in some sense, but that's quite an
ugly one :)
>> receiver just can't be used without the "self." prefix...
>
> Yes, it is kind of silly and I'm suprised it can't be handled. I've
> suggested __class__ before as a reserved backup, though that isn't all
> that succinct either.
Well, I came to the conclusion that I'll add a "cl" instance method to
those classes where it's a concern. (Maybe "_cl", or make it private if
namespace pollution is an issue.)
Csaba