What is the right way to initialize a constant in Ruby?

Question

I have a simple class that defines some constants, e.g.:

module Foo
  class Bar
    BAZ = "bof"
    ...

Everything is puppies and rainbows until I tell Rake to run all my Test::Unit tests. When it does, I get warnings:

bar.rb:3: warning: already initialized constant BAZ

My habit has been to avoid these warnings by making the constant initialization conditional, e.g.:

...
BAZ = "bof" unless const_defined? :BAZ
...

This seems to solve the problem, but it is a little tedious, and I don't ever see anyone else initializing constants this way. This makes me think I might be Doing It Wrong. Is there a better way to initialize constants that won't generate warnings?

Update: By way of a little more detail on how I'm using these constants, let's say I've defined a Token class that has constants for all the characters that are part of the syntax of some artificial language. I also have a Scanner class that reads a stream of characters, generating a Token instance for each one.

module Foo
  class Token
    LPAREN = "("
    RPAREN = ")"
    ...
  end

  class Scanner
    def next_token
      case read_char()
        when Token::LPAREN: # Generate a new LPAREN token
        ...

That is, when checking to see what kind of token should be generated for the given character, I want to use the constants defined in Token.

Update 2: Jörg's answer revealed that the problem was probably in how I was constructing paths in my require statements, not in how I was initializing or using the constants. I rewrote my require statements to eliminate any manual path creation, e.g.:

# File: $PROJECT_ROOT/lib/foo.rb; trying to load $PROJECT_ROOT/lib/foo/bar.rb
require File.expand_path(File.dirname(__FILE__)) + "foo/bar"

is now written to rely on $LOAD_PATH:

# File: $PROJECT_ROOT/lib/foo.rb; trying to load $PROJECT_ROOT/lib/foo/bar.rb
require 'lib/foo/bar'

I removed the conditional checks from my constant initialization statements, and rake now runs unit tests without throwing any warnings.

Answer 1

The only way this can happen, is when bar.rb is required multiple times. Which shouldn't happen, since require doesn't load files that have already been loaded once.

It does, however, only use the path you pass to it to determine whether a file has already been loaded, at least in Ruby 1.8:

require 'bar'   # => true, file was loaded

require 'bar'   # => false, file had already been loaded

require './bar' # => true, OOPS, I DID IT AGAIN
# bar.rb:3: warning: already initialized constant BAZ

So, you are right: this could very well be an indication that there is something wrong with your dependency management.

Typical warning signs are

• manually constructing file paths instead of just relying on $LOAD_PATH

  require "File.expand_path('../lib/bar', File.dirname(__FILE__))"
  

• manipulating $LOAD_PATH anywhere except maybe the main entry point to your library:

  path = File.expand_path(File.dirname(__FILE__))
  $LOAD_PATH << path unless $LOAD_PATH.include?(path)
  

In general, my philosophy is that it's not my job as a library writer to figure out how to put my library on the $LOAD_PATH. It's the system administrator's job. If the sysadmin uses RubyGems to install my library, then RubyGems will take care of it, otherwise whatever other package management system he uses should take care of it, and if he uses setup.rb, then it will be installed in site_ruby, which is already on the $LOAD_PATH anyway.

Answer 2

There's a good discussion on this in the comments on this post. I think the following one puts it nicely:

This irked me somewhat when I first walked up to Ruby. It was a remnant of my static type brainwashing. Three things mitigate against this being a real problem. 1. The warning. You could argue it should be an exception, but in reality, how would that be any different in the case where some other programmer silently caught the exception? Which brings me to number 2) Don't work with morons. Only morons silently catch exceptions and continue and only morons change constant values used in that way. Which brings me to 3) Neither of us is a moron, so you'll be happy to know that anecdotally this has never happened to me. It's really because constants stand out in Ruby anyway, what with their upcase, and how often are you likely to have a constant as an L-value in your code?

To directly answer your question, I wouldn't do anything to get rid of the warning. Just take the warning as just that, a warning, and move on.