“sensible_defaults! iterates over the DEFAULT_OPTIONS hash rather than using Hash#merge because Hash#merge clobbers things in the destination hash, and the point of the exercise is to set those defaults only when the user hasn’t specified a value.”

Would ActiveSupport’s reverse_merge work better in this case?
http://api.rubyonrails.org/classes/ActiveSupport/CoreExtensions/Hash/ReverseMerge.html

I don’t know RoR at all, so the code was only fairly educational, but your explanation was really easy to understand. One thing I was curious about though was when you were reiterating over the Default_options array to set the user prefs. Does RoR not have an array_merge function?

For example, if you find yourself needing to interact with one of those properties a lot in the code, you need to ask yourself if that property is starting to emerge as an important part of the design. The magic question is, “if I forget to put this key in the hash stored in the database, will other client code break?” (My rule of thumb: if it requires a change in the view, leave it in the hash; if it requires a change in a model, extract it to its own column.)

Secondly, trading lines of negacode for a general solution is also a +/- proposition. I agree with your position and favor general code over specific (can you tell that I refuse to ever program in Java again?), but the counterarguments go like this: First, 200 lines of repetetive code really only as complex as the 10 lines of boilerplate code that are repeated; second, general code may give you those 20 properties, but it will also open you up to an infinite number of OTHER properties and you cannot guarantee that they will work, or worse, that they cannot be exploited maliciously.” This counterargument almost always comes from somebody who is used to programming in a more “explicitly safe” language like Java or C# or Python.

Third, the maintainer of your code can see that whatever you put in that options hash will get extended onto your model. That’s great! But what the maintainer CAN’T see is what those options are supposed to be. She can’t look at the source and see “def color”. You might say this argument is weak in rails since you’d have to look at the schema anyway, but it’s a stronger argument than you think: the schema can be found in schema.rb. The options hash must be populated by something first before she can look at it. In other words, if she’s got an empty database she can’t save an exemplar because she doesn’t know what properties should be put into the options. She’s stranded.

Okay, enough doom and gloom! I love this technique. It’s powerful, is all I’m saying, and care should be exercised. Powerful tools used ignorantly are merely dangerous.

Boo to “best practices”, hooray for a healthy dose of pragmatism.

@print_job.sensible_defaults!

you could also do the initialization of the sensible_defaults in the after_initialize callback method, so you don’t have to do it in the controller ( which matters more if you call this a lot, and are afraid you’ll forget to do it)