# Succint access to constants/class methods? **URL:** \ **Category:** ruby-talk\ **Created:** [19 February 2005 03:14 UTC](https://rubytalk.org/t/succint-access-to-constants-class-methods/16608 "2005-02-19T03:14:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Csaba\_Henk4](https://avatars.discourse-cdn.com/v4/letter/c/9f8e36/32.png) [@Csaba\_Henk4](https://rubytalk.org/u/Csaba_Henk4)\ **Post date:** [19 February 2005 03:14 UTC](https://rubytalk.org/t/succint-access-to-constants-class-methods/16608/1 "2005-02-19T03:14:45Z")
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.) > > Csaba ---
**Author:** ![James\_Britt6](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@James\_Britt6](https://rubytalk.org/u/James_Britt6)\ **Post date:** [19 February 2005 04:20 UTC](https://rubytalk.org/t/succint-access-to-constants-class-methods/16608/2 "2005-02-19T04:20:57Z")
Csaba Henk wrote: > 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: > **[WebMD - Better information. Better health.](https://www.webmd.com/?ClassMethodsTutorial)** > > The leading source for trustworthy and timely health and medical news and information. Providing credible health information, supportive community, and educational services by blending award-winning expertise in content, community services, expert... James ---
**Author:** ![Csaba\_Henk4](https://avatars.discourse-cdn.com/v4/letter/c/9f8e36/32.png) [@Csaba\_Henk4](https://rubytalk.org/u/Csaba_Henk4)\ **Post date:** [19 February 2005 07:24 UTC](https://rubytalk.org/t/succint-access-to-constants-class-methods/16608/3 "2005-02-19T07:24:45Z")
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 \ wrote: > > > This may not give you quite the answer you are looking for, but it may > > help explain the behavior you are seeing: > > > > [http://www.rubygarden.org/ruby?ClassMethodsTutorial](http://www.rubygarden.org/ruby?ClassMethodsTutorial) ---
**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\ **Post date:** [21 February 2005 15:59 UTC](https://rubytalk.org/t/succint-access-to-constants-class-methods/16608/4 "2005-02-21T15:59:41Z")
> 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. T.