Michael J. McDermott's Profile

I think the only performance issue would be load time. Loading the class is probably quicker than parsing the YAML and then loading the relevant data structures. I've never done a compare, but I'd imagine the difference would not matter much.

I just wondered whether setting up a nested data structure is spartan enough in Ruby that the YAML abstraction is often unnecessary.

I like YAML, and when I use Rails, that's how it works, so I use it. But when I've been doing non-rails stuff lately, I've been experimenting with just using Ruby, e.g.:

module Config

  @ldap_array =     {
        :host => 'server',
        :port => 636,
        :base => '[base]',
        :method => :ssl,
        :bind_dn => "bind_dn",
        :password_block => Proc.new { '[password]' },
        :allow_anonymous => false,
        :try_sasl => false
    }

  def self.ldap_settings
    @ldap_array
  end

end

and then I can use it like:

class LdapThingee
  include Config

  def some_method()
    LdapPerson.setup_connection(Config.ldap_settings)
  end
end

As best as I can figure, YAML lets you not worry about quoting strings. But the portability of YAML is not really a big selling point for configs in Ruby. In Java, XML was a idea since it meant you could use a standard, portable format, that didn't get compiled into your code. YAML's readability is a big improvement from XML for configs. But since the Ruby doesn't get compiled, why not use it for configs I wondered?

Since Ruby is an interpreted language, what is the drawback to storing configurations/settings in a simple ruby hash in an rb file/Ruby module and then include the file/module? What advantage does parsing a YAML file into a simple ruby data structure yield since Ruby is already pretty darn readable?

I know you could make arguments that you might include your real config file in version control, but that's true for YAML et al. as well.