March 7, 2015 by Daniel P. Clark

Configuration With a Singleton Instance

I was considering how I might want to further implement my gem and incorporate configuration settings for it.  I wanted only one instance of my configuration and it needed to be part of my module.  So I’ve come up with a solution I like that allows me to do this and even have a true “sense” of untouchable constants.

I’ve found OpenStruct to be for my liking in this situation as it allows for any configuration (variable) to be set on it.  I’ve also found I can set “unalterable” variables… at least through standard assignment options.

Here’s the basics of it:

The reason I created the class MyProject::MyConfig just to inherit OpenStruct is that I want my configuration to be identified by a class name that indicates it is a config object that belongs to my project.  In module MyProject I use attr_reader for config because we are getting the OpenStruct instance handed back to us and we can still invoke method/value assignment on it.  I use the single class variable @config for the internal singleton value because it’s not going anywhere (No need to use @@config).  The method config is defined on the singleton instance of the module MyProject via the class << self.  So to set any value all I need to do is MyProject.config.new_value = 42.

If I want to set a constant value that I don’t want to change then all I have to do is define the method within the OpenStruct instance.  You can do it in the class, or open it up with the singleton opener.

If you want a default value that can be updated; then you may implement that method with a method_missing(:method_name) || :value .  As soon as you assign a new value it will choose the updated value.


So now you can have a single instance configuration that’s easily updatable and you can set values that you don’t want to change.  I do realize that the “constants” in this case aren’t defined the way the language normally defines constants.  But in this situation it’s what works… and it works better than constants that don’t truly stay constant when reassigned ;-).

I hope this was informative and enjoyable for you!  Please feel free to comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!

God Bless!
-Daniel P. Clark

Image by murray 9000 via the Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic License

0 0 vote
Article Rating
Notify of
Newest Most Voted
Inline Feedbacks
View all comments
Sergey Avseyev
7 years ago

when defining only one class method, it will be more clear to use ‘def self.config’ form

why don’t you want to catch all sets to ‘constant’ value using ‘undef :no_touchy=’? It will raise undefined method error

Daniel P. Clark
7 years ago
Reply to  Sergey Avseyev

Thanks Sergey!

I believe ‘def self.config‘ wouldn’t be a good solution for me. The reason is that it defines a method on the module that can be inherited. That isn’t what I wanted. I wanted only one instance of config to exist so I opened up the anonymous singleton that exists on the module. The use of the shovel operator < < allows us to open anonymous singletons that belong to each object and are never inherited.

With OpenStruct every undefined method gets handed to method_missing which it has implemented to work like a Hash store.


Because of OpenStruct’s use of method_missing; undef will not produce an “undefined method error”.

7 years ago

Hey Dan,

Solid introduction to configuration with a singleton instance! Though you will sometimes see people treat configuration objects similar to the one you describe as a more traditional singleton rather than as a singleton instance, singleton instance is definitely the way to go. A singleton instance is much more testable than an actual singleton and in my experience it is not infrequent that it becomes necessary to have another instance of the configuration object, typically for a subclass of the class originally requiring configuration.

In regard to the “max_limit” example you provide for handling default values, it’s a minor optimization, but you might consider using the __method__ method when calling method_missing instead of referring to :max_limit directly. It’s a little DRYer which means fewer places that the name “max_limit” would need to be changed if you decided to rename the method and less opportunity for weird bugs to occur. In more concrete terms, that would look like:


It might be DRYer still to implement your own version of method_missing if you have a lot of accessors that have default values. For example, something along the lines of:


Unfortunately, all these options run into trouble if the user-defined configuration value is nil or false. If support for falsy values is needed in a situation where the configuration value also has a default, it’d be worth looking into the inner workings of OpenStruct and seeing what options are available to determine if a key has been defined or if there’s a means of calling something along the lines of Hash#fetch as this can be a better option as demonstrated in this post on the matter by Avdi Grimm. Anyway, please don’t take these suggestions as a criticism, I definitely prefer to keep things simpler where it is possible, but edge cases often emerge.

Thanks for sharing!

Daniel P. Clark
7 years ago
Reply to  tdg5

Thanks Danny!

I hadn’t used the __method__ method before. Thanks for the tip! And I like your suggestion on defining your own method_missing. Definitely will keep default values cleaner.

You were right about looking into the internals of OpenStruct. As to allowing nil or false; the internal Hash is @table so something like this works well.


Now max_limit can be implemented as so.

def max_limit
  fetch(__method__) { 42 }
Andrew Kozin
Andrew Kozin
7 years ago

Hi, Daniel!

Thanks for the post, it’s really helpful.

One thing I cannot figure out is the purpose of `attr_reader :config` in the `MyProject` module. AFAIK, the only place it will work is the class including (or extended by) `MyProject`.

But it simply return `nil` ’cause no setter has been defined.

What it is needed for? Could you put some example?

Daniel P. Clark
7 years ago
Reply to  Andrew Kozin

Good catch! Actually it’s not needed and is a bit misleading. In the process of figuring out how to implement this feature I had put that in and just left it there. But in fact it does nothing for the configurable object. So I apologize to you for that.

The only setter methods available should be for the OpenStruct instance created on the Object config which only resides with the singleton instance on MyProject.

Robert Fletcher
Robert Fletcher
7 years ago

I use the singleton strategy like this, but the problem with using

is that it fails silently for invalid options. So if I type

I’ll be none the wiser. Instead I go the long hand route and create a class with its own accessors for the configurations I want to be able to set. Another convenience I like to add is a block method for tidier configuration in my code:


I like to refer to other libraries such as RSpec for ideas on this:

Daniel P. Clark
7 years ago

I see your point. I guess it depends on how strict/tight you want to control it. I’m open to learning better ways. How does the yield(config) work? Are my_cool_option and my_other_option predefined on MyClass before the configure block is called?

Robert Fletcher
Robert Fletcher
7 years ago

I guess I glossed over that a bit. Here’s a more complete example:


Then you can use it in two different ways:


just passes the

instance into the block.

Daniel P. Clark
7 years ago

Very nice! Thanks for sharing it!