Accessor for Class Variable

I know it's a stupid question, but I can't find the answer...

Isn't there another way to have an accessor for a class variable than a "def"??? Something like "attr_reader"?

class Outing < ActiveRecord::Base
  @@planingList = [ "YES", "NO", "YES/NO"]
  
   def Outing.wind_directionList
    return @@wind_directions
   end
end

If the answer is somewhere in the docs, please point me to it.

Thank you

"Leonardo Francalanci" <lfrancalanci@simtel.it> schrieb im Newsbeitrag
news:4267B13A.20905@simtel.it...

I know it's a stupid question, but I can't find the answer...

Isn't there another way to have an accessor for a class variable than a
"def"??? Something like "attr_reader"?

Not AFAIK.

class Outing < ActiveRecord::Base
@@planingList = [ "YES", "NO", "YES/NO"]

   def Outing.wind_directionList
  return @@wind_directions
   end
end

In your case you could as well do

class Outing < ActiveRecord::Base
  @planingList = [ "YES", "NO", "YES/NO"]

  class<<self; attr_reader :planingList end
end

Outing.planingList

=> ["YES", "NO", "YES/NO"]

Class variables are really only useful if you want to access them from
instances and from the class in a similar way (via "@@var_name").
Otherwise they have more drawbacks than pros so I avoid to use them
whenever I can. (Can't really remember a case where I actually needed
them.)

Kind regards

    robert

Leonardo Francalanci ha scritto:

I know it's a stupid question, but I can't find the answer...

Isn't there another way to have an accessor for a class variable than a "def"??? Something like "attr_reader"?

class Outing < ActiveRecord::Base
    @@planingList = [ "YES", "NO", "YES/NO"]
      def Outing.wind_directionList
      return @@wind_directions
  end
end

If the answer is somewhere in the docs, please point me to it.

AFAIK there is not, I think you're supposed to access a class variable directly from instances and class methods, and to generally use a constant when possible, wich is visible from outside.
In general the use case for class attributes accessible from the outside is not that much (in my own experience).

Anyway you should be able to write them easily with something like (untested):

class Class
  def class_attr sym
   module_eval "def self.#{sym}() @@#{sym} end"
   module_eval "def self.#{sym}=(x) @@#{sym}=x end"
  end
end

class C
  class_attr :foo
end

Actually, Rails includes a mechanism to allow class attributes. I
believe the usage is

class Whatever
  @@varname = "Default Value"
  cattr_accessor :varname
end

I'm not sure if it is documented anywhere though. You can see some
examples here:
http://dev.rubyonrails.com/file/trunk/actionpack/lib/action_controller/base.rb

···

On 4/21/05, Leonardo Francalanci <lfrancalanci@simtel.it> wrote:

I know it's a stupid question, but I can't find the answer...

Isn't there another way to have an accessor for a class variable than a
"def"??? Something like "attr_reader"?

  class<<self; attr_reader :planingList end

Aaargh... what is that? What does it mean?
Sorry, I'm coming from Java...

AFAIK there is not, I think you're supposed to access a class variable directly from instances and class methods, and to generally use a constant when possible, wich is visible from outside.
In general the use case for class attributes accessible from the outside is not that much (in my own experience).

Ok, got it, I changed them into constants.

Anyway you should be able to write them easily with something like (untested):

class Class
  def class_attr sym
   module_eval "def self.#{sym}() @@#{sym} end"
   module_eval "def self.#{sym}=(x) @@#{sym}=x end"
  end
end

class C
  class_attr :foo
end

Wow, looks like I have to learn a lot of stuff...

What about situations like the following ( taken from an attempt at an
old rubyquiz )

class Op
    @@lookup = {}
    def Op.register(newOp, newOpClass)
       @@lookup[newOp] = newOpClass
    end
end

class AddOp < Op
...
end
class SubOp < Op
...
end
class MulOp < Op
...
end
class DivOp < Op
...
end

Op.register("+", AddOp)
Op.register("-", SubOp)
Op.register("*", MulOp)
Op.register("/", DivOp)

They are not really OO 'clean' but better than globals surely?

···

On 4/22/05, Robert Klemme <bob.news@gmx.net> wrote:

Class variables are really only useful if you want to access them from
instances and from the class in a similar way (via "@@var_name").
Otherwise they have more drawbacks than pros so I avoid to use them
whenever I can. (Can't really remember a case where I actually needed
them.)

--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.

Leonardo Francalanci ha scritto:
<snip>

Wow, looks like I have to learn a lot of stuff...

not that much, really, there are a few concepts in ruby with a lot of usages :slight_smile:
Anyway, assuming you're italian, I thought I'd point out that there is a (low traffic) mailing list for italian people that you can subscribe from
http://ada2.unipv.it/ruby

ciao

"Leonardo Francalanci" <lfrancalanci@simtel.it> schrieb im Newsbeitrag
news:4267B7A4.6060708@simtel.it...

> class<<self; attr_reader :planingList end

Aaargh... what is that? What does it mean?
Sorry, I'm coming from Java...

Then you'll never know... *evil grin*

Ok, class << x ... end is the singleton class of that instance. You can
use that to define methods for a certain instance only (in this case it's
the class). Some examples:

17:20:35 [robert.klemme]: irb
irb(main):001:0> obj = Object.new
=> #<Object:0x101949b8>
irb(main):002:0> def obj.foo() "foo" end
=> nil
irb(main):003:0> obj.foo
=> "foo"
irb(main):004:0> class <<obj
irb(main):005:1> def bar() "<<" + foo() + ">>" end
irb(main):006:1> end
=> nil
irb(main):007:0> obj.bar
=> "<<foo>>"

As a class is an object much like every other object, you can also define
singleton methods for them:

irb(main):008:0> def String.foo() "foo" end
=> nil
irb(main):009:0> String.foo
=> "foo"
irb(main):010:0> class <<String
irb(main):011:1> def bar() "<<" + foo() + ">>" end
irb(main):012:1> end
=> nil
irb(main):013:0> String.bar
=> "<<foo>>"
irb(main):014:0>

Does that help?

Kind regards

    robert

"Lyndon Samson" <lyndon.samson@gmail.com> schrieb im Newsbeitrag
news:a39f6ad0050421082652ed737e@mail.gmail.com...

>
>
> Class variables are really only useful if you want to access them from
> instances and from the class in a similar way (via "@@var_name").
> Otherwise they have more drawbacks than pros so I avoid to use them
> whenever I can. (Can't really remember a case where I actually needed
> them.)
>
What about situations like the following ( taken from an attempt at an
old rubyquiz )

class Op
    @@lookup = {}
    def Op.register(newOp, newOpClass)
       @@lookup[newOp] = newOpClass
    end
end

class AddOp < Op
..
end
class SubOp < Op
..
end
class MulOp < Op
..
end
class DivOp < Op
..
end

Op.register("+", AddOp)
Op.register("-", SubOp)
Op.register("*", MulOp)
Op.register("/", DivOp)

They are not really OO 'clean' but better than globals surely?

Yes, but you still don't need a class var - a standard instance var of the
class is sufficient, as you can see:

class Op
    @lookup = {}
    def self.register(newOp, newOpClass)
       @lookup[newOp] = newOpClass
    end
end

.... and even saves two chars typing that I could use to replace "Op" by
"self" in the method definition :-)))

Kind regards

    robert

···

On 4/22/05, Robert Klemme <bob.news@gmx.net> wrote:

Sorry, I'm coming from Java...

Then you'll never know... *evil grin*

I knew I shouldn't have said that :wink:

Ok, class << x ... end is the singleton class of that instance. You can
use that to define methods for a certain instance only (in this case it's
the class).

As a class is an object much like every other object, you can also define
singleton methods for them

Ok, thanks!

Anyway, assuming you're italian, I thought I'd point out that there is a (low traffic) mailing list for italian people that you can subscribe from
http://ada2.unipv.it/ruby

thanks,

ciao!

Yes, but you still don't need a class var - a standard instance var of the
class is sufficient, as you can see:

class Op
   @lookup = {}
   def self.register(newOp, newOpClass)
      @lookup[newOp] = newOpClass
   end
end

.... and even saves two chars typing that I could use to replace "Op" by
"self" in the method definition :-)))

Ahh, lightbulbs are going off all over the place here :slight_smile:

Java has nothing analogous to Class instance variables so i've be
using class variables like statics. But classes are Objects, so why
not treat them likewise. You can even have real singletons in Ruby,
unlike Java where a singleton is unqiue to a ClassLoader.

To paraphrase Alice, cooler and cooler...

···

On 4/23/05, Robert Klemme <bob.news@gmx.net> wrote:

Kind regards

   robert

--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.

"Leonardo Francalanci" <lfrancalanci@simtel.it> schrieb im Newsbeitrag
news:4267CC3F.5030404@simtel.it...

>>Sorry, I'm coming from Java...
>
> Then you'll never know... *evil grin*

I knew I shouldn't have said that :wink:

:-)) I'm coming from Java, too. But, psst, don't tell anyone!

> Ok, class << x ... end is the singleton class of that instance. You

can

> use that to define methods for a certain instance only (in this case

it's

> the class).

> As a class is an object much like every other object, you can also

define

> singleton methods for them

Ok, thanks!

You're welcome

    robert

"Lyndon Samson" <lyndon.samson@gmail.com> schrieb im Newsbeitrag news:a39f6ad005042208506431c466@mail.gmail.com...

Yes, but you still don't need a class var - a standard instance var of the
class is sufficient, as you can see:

class Op
   @lookup = {}
   def self.register(newOp, newOpClass)
      @lookup[newOp] = newOpClass
   end
end

.... and even saves two chars typing that I could use to replace "Op" by
"self" in the method definition :-)))

Ahh, lightbulbs are going off all over the place here :slight_smile:

/me puts on his sunglasses.

Java has nothing analogous to Class instance variables so i've be
using class variables like statics. But classes are Objects, so why
not treat them likewise. You can even have real singletons in Ruby,
unlike Java where a singleton is unqiue to a ClassLoader.

.... which isn't necessarily bad: think of a ClassLoader as an application context (a good example is an app server like Tomcat). You wouldn't want one apps singletons mess with another apps singletons - at least not automatically.

To paraphrase Alice, cooler and cooler...

:slight_smile:

Glad I could help.

CU

    robert

···

On 4/23/05, Robert Klemme <bob.news@gmx.net> wrote: