One of the things I deeply like in ruby that succintness is an intrinsic
design principle.
Ruby is just the opposite of that what the infamous standard Java
"hello world" encapsulates. In general. But it seems to me that there
are some problem with proper access to constants and class methods and
succintness.
See a naive code:
···
####
class A
C = 0
def self.bar
""
end
def foo
[A.bar,C]
end
end
class B < A
end
B.new.foo # => ["",0]
####
-- this is succint, and works as it should. But what if we make up our
mind so that B should roll its own?
####
class B
C = 1
def self.bar
"x"
end
end
B.new.foo # => ["",0]
# bummer...
####
If we want the reference to the constant and the class method be
properly dispatched on B (provided B has them), we have to modify
A#foo as follows:
####
class A
def foo
[self.class.bar, self.class::C]
end
end
B.new.foo # => ["x",1]
# that's it!
####
But succintess is lost here. Does anyone know a better way of doing it?
What's extra annoyance that you have to write the longish "self.class",
and not just "class", as this latter would be mistaken with the reserved
word "class". Why is there no an alternative for Object#class which
doesn't collide with a reserved word? (There is Object#type, but that's
deprecated, and you are warned to use Object#class.)
One of the things I deeply like in ruby that succintness is an intrinsic
design principle.
Ruby is just the opposite of that what the infamous standard Java
"hello world" encapsulates. In general. But it seems to me that there
are some problem with proper access to constants and class methods and
succintness.
This may not give you quite the answer you are looking for, but it may help explain the behavior you are seeing:
Yes, I know class methods are just singleton methods of classes, thus
it's quite clear that if I use A.foo then that message "foo" will be
dispatched at A and nobody else.
Contsants are more ambigouos. When you refer to the contsant C in an
instance method just this way, writing a letter C, it's not specified
explicitely whom should be the receiver.
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.
How many of you would disagree would disagree with the above paragraph?
And how many of you uses self.class::C in her/his own code, rather than
just the plain simple comfortable C?
And it's such a stupid accident that the method which sets the right
receiver just can't be used without the "self." prefix...
Csaba
···
On 2005-02-19, James Britt <jamesUNDERBARb@neurogami.com> wrote:
This may not give you quite the answer you are looking for, but it may
help explain the behavior you are seeing:
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.
And it's such a stupid accident that the method which sets the right
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.