Attempt to look up non-existing settings in parent classes (see #21)#55
Attempt to look up non-existing settings in parent classes (see #21)#55britishtea wants to merge 1 commit intosoveran:masterfrom
Conversation
…an#21) This fixes an issue where settings are added to Cuba.settings *after* inheriting from `Cuba` are not picked up by the child classes. The problem is described in issue soveran#21. If a setting does not exist, Settings are looked up in the settings Hash of the parent class using `Hash#default_proc`. The settings Hash is still deepcloned, so settings are still overridable.
There was a problem hiding this comment.
I'm curious. Why the respond_to??
{}.respond_to?(:default_proc) # => trueThere was a problem hiding this comment.
I took a clue from the argument name (obj). Because Cuba.deepclone is part of the public API, this patch could break code that calls Cuba.deepclone with anything other than a Hash.
There was a problem hiding this comment.
Nice. Thanks for replying :-)
|
I personally solved this issue without deep cloning via
I am using this cuba-plugin https://github.com/mkristian/cuba-api/blob/master/lib/cuba_api/config.rb |
|
I added a comment, please let me know what you guys think: #21 (comment) |
4 participants
This fixes an issue where settings are added to Cuba.settings after inheriting from
Cubaare not picked up by the child classes. The problem is described in issue #21.If a setting does not exist, settings are looked up in the settings Hash of the parent class using
Hash#default_proc. The settings Hash is still deepcloned, so settings are still overridable.