succint access to constants/class methods?

Discussion in 'Ruby' started by Csaba Henk, Feb 19, 2005.

  1. Csaba Henk

    Csaba Henk Guest

    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
    Csaba Henk, Feb 19, 2005
    #1
    1. Advertising

  2. Csaba Henk

    James Britt Guest

    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:

    http://www.rubygarden.org/ruby?ClassMethodsTutorial


    James
    James Britt, Feb 19, 2005
    #2
    1. Advertising

  3. Csaba Henk

    Csaba Henk Guest

    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


    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
    Csaba Henk, Feb 19, 2005
    #3
  4. Csaba Henk

    Trans Guest


    > 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.
    Trans, Feb 21, 2005
    #4
  5. Csaba Henk

    Csaba Henk Guest

    On 2005-02-21, Trans <> 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
    Csaba Henk, Feb 21, 2005
    #5
  6. Csaba Henk

    Csaba Henk Guest

    On 2005-02-21, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
    > Btw, redefining a constant in a subclass doesn't trigger that warning.


    [snip]

    > defines a fresh new Foo, exclusively for B, with that value. No constant
    > has been redefined...


    To avoid confusion, I should have written:

    Btw, "redefining a constant in a subclass" doesn't trigger that warning.

    Csaba
    Csaba Henk, Feb 21, 2005
    #6
  7. Csaba Henk

    Guest

    Trans 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.


    Constant = An accessor for a "frozen" instance variable ?
    , Feb 23, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Oltmans
    Replies:
    6
    Views:
    341
    Terry Reedy
    Mar 11, 2009
  2. Ara.T.Howard
    Replies:
    3
    Views:
    123
    Robert Klemme
    Feb 16, 2004
  3. Jeff Davis
    Replies:
    0
    Views:
    75
    Jeff Davis
    Jan 30, 2005
  4. Kenneth McDonald
    Replies:
    5
    Views:
    313
    Kenneth McDonald
    Sep 26, 2008
  5. Marli Ba
    Replies:
    3
    Views:
    85
    Marli Ba
    Oct 15, 2009
Loading...

Share This Page