Live data from Hacker News

Ruby Gem Configuration Patterns

brandonhilkert.com

11–13 of 13 posts

Re: Ruby Gem Configuration Patterns

#11
post #6
post #5

This is actually a very complicated way of achieving the goal. It works, but it's not good from an economic point of view as it is more expensive in computational terms than a simpler OO alternative, which is to pass the size when you instantiate the MegaLotto::Drawing object. For example, compare the proposed solution: MegaLotto.configure do |config| config.drawing_count = 10 end MegaLotto::Drawing.new.draw With the…

Right...but even in this trivial gem, there may be the need to configure more than one parameter. And by having Configuration be it's own object, you can encode some validation logic at the configuration stage. I do agree that the constructor should have the option of passing in a Hash, which is then passed directly to the Configuration option.

Yup. It's configuration management.

A setting maybe needed per app, per process, per thread, per class|module, per subclass|include/extended module, per instance or per method call. (Phew.) And that's probably only 90% of use-cases, not counting apps configured by something like a JSON api, ZooKeeper or Chef databags.

The trick is to isolate config from behavior out of code as much as possible, scala style. An obvious example is to use environment variables so apps can be reconfigured without touching code.

Re: Ruby Gem Configuration Patterns

#12
post #5

This is actually a very complicated way of achieving the goal. It works, but it's not good from an economic point of view as it is more expensive in computational terms than a simpler OO alternative, which is to pass the size when you instantiate the MegaLotto::Drawing object. For example, compare the proposed solution: MegaLotto.configure do |config| config.drawing_count = 10 end MegaLotto::Drawing.new.draw With the…

It can be simplified even more:

    megalotto = MegaLotto.new
    megalotto.draw(10)

Re: Ruby Gem Configuration Patterns

#13
post #5

This is actually a very complicated way of achieving the goal. It works, but it's not good from an economic point of view as it is more expensive in computational terms than a simpler OO alternative, which is to pass the size when you instantiate the MegaLotto::Drawing object. For example, compare the proposed solution: MegaLotto.configure do |config| config.drawing_count = 10 end MegaLotto::Drawing.new.draw With the…

This pattern is meant to enact a single, global configuration, so the extra allocations are not likely to affect performance noticeably.
Post reply on HN