Professional Web Applications Themes

Constant visibility - Ruby

Folks, I know this sort of thing has been talked about before, but that's not going to stop me :) module M X = 5 class C def foo puts "X = #{X}" end end end class M::C def bar puts "X = #{X}" end end M::C.new.foo # X = 5 M::C.new.bar # NameError: uninitialized constant M::C::X The problem is that when you use 'class M::C' to open a class, you can't access constants declared in M, whereas if you use 'module M; class C', you can. 1) Why is this? 2) Is is an intentional behaviour of Ruby? I ...

  1. #1

    Default Constant visibility

    Folks,

    I know this sort of thing has been talked about before, but that's not
    going to stop me :)

    module M
    X = 5
    class C
    def foo
    puts "X = #{X}"
    end
    end
    end

    class M::C
    def bar
    puts "X = #{X}"
    end
    end

    M::C.new.foo # X = 5
    M::C.new.bar # NameError: uninitialized constant M::C::X


    The problem is that when you use 'class M::C' to open a class, you
    can't access constants declared in M, whereas if you use 'module M;
    class C', you can.

    1) Why is this?

    2) Is is an intentional behaviour of Ruby?


    I feel fairly confident that the new constant resolution rules will
    sort this out, but I'm wondering why it can't be made to work now.

    ruby 1.8.1 (2004-01-08) [i386-cygwin]

    Gavin





    Gavin Guest

  2. #2

    Default Re: Constant visibility


    "Gavin Sinclair" <com.au> schrieb im Newsbeitrag
    news:com.au... 

    Because when doing "class M::C" you're still in another scope while defining
    class C. So you have to explicitely scope constants from module M. (see
    below)
     

    I think so.
     

    irb(main):014:0> module M
    irb(main):015:1> X = 5
    irb(main):016:1> class C
    irb(main):017:2> def foo
    irb(main):018:3> puts "X = #{X}"
    irb(main):019:3> end
    irb(main):020:2> end
    irb(main):021:1> end
    => nil
    irb(main):022:0>
    irb(main):023:0* class M::C
    irb(main):024:1> def bar
    irb(main):025:2> puts "X = #{M::X}"
    irb(main):026:2> end
    irb(main):027:1> end
    => nil
    irb(main):028:0>
    irb(main):029:0* M::C.new.foo
    X = 5
    => nil
    irb(main):030:0> M::C.new.bar
    X = 5
    => nil
    irb(main):031:0>

    $ ruby --version
    ruby 1.8.1 (2003-12-25) [i386-cygwin]

    Regards

    robert

    Robert Guest

  3. #3

    Default Re: Constant visibility

    On Sunday, February 1, 2004, 10:19:53 PM, Robert wrote:

     [/ref]
     

    "Another scope"? Sounds convincing, but I don't know what it means.
    'self' is the same object in the following two examples:

    module M
    class C
    p self.id
    end
    end

    class M::C
    p self.id
    end
     [/ref]
     

    Can it be justified in terms of correctness, language design
    principles, POLS, convenience, expedience, or anything else?

    To my mind, the way things work (scope-wise) should depend on the
    value of 'self' and little if not nothing else.

    Cheers,
    Gavin



    Gavin Guest

  4. #4

    Default Re: Constant visibility

    >>>>> "G" == Gavin Sinclair <com.au> writes:

    G> To my mind, the way things work (scope-wise) should depend on the
    G> value of 'self' and little if not nothing else.

    well, another example to see that ruby sometimes use something else than
    self

    svg% ruby -e 'Array.instance_eval { p self; def a() puts "a"; end }; Array.a'
    Array
    a
    svg%

    svg% ruby -e 'Array.module_eval { p self; def a() puts "a"; end }; [].a'
    Array
    a
    svg%



    Guy Decoux


    ts Guest

  5. #5

    Default Re: Constant visibility


    "Gavin Sinclair" <com.au> schrieb im Newsbeitrag
    news:com.au... [/ref]
    > [/ref]
    defining 
    >
    > "Another scope"? Sounds convincing, but I don't know what it means.
    > 'self' is the same object in the following two examples:
    >
    > module M
    > class C
    > p self.id
    > end
    > end
    >
    > class M::C
    > p self.id
    > end[/ref]

    It's the other self, the one that is used for the const lookup I guess:

    module M
    p self.id

    class C; end
    end

    p self.id
    class M::C;end

     [/ref]

    >
    > Can it be justified in terms of correctness, language design
    > principles, POLS, convenience, expedience, or anything else?
    >
    > To my mind, the way things work (scope-wise) should depend on the
    > value of 'self' and little if not nothing else.[/ref]

    see above. Just my 0.02 EUR

    robert

    Robert Guest

  6. #6

    Default Re: Constant visibility

    On Sunday, February 1, 2004, 11:07:11 PM, ts wrote:
     [/ref][/ref]

    G>> To my mind, the way things work (scope-wise) should depend on the
    G>> value of 'self' and little if not nothing else.
     
     
     


    Good point. Still the exception rather than the rule, I hope :)

    Gavin




    Gavin Guest

Similar Threads

  1. cfselect visibility
    By hollyjones in forum Coldfusion Flash Integration
    Replies: 0
    Last Post: August 11th, 09:04 PM
  2. Set visibility via asp
    By mr_tim in forum Macromedia Flash Data Integration
    Replies: 3
    Last Post: May 25th, 06:50 AM
  3. visibility
    By Simon in forum Microsoft Access
    Replies: 2
    Last Post: September 9th, 08:05 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139