-
Notifications
You must be signed in to change notification settings - Fork 258
Description
Cuba.settings[ :state ] = Proc.new { "ok" }
class A < Cuba; end
just does not work. some with singletons, lambdas, methods, etc
I solved the problem for myself with this plugin
https://github.com/mkristian/cuba-api/blob/master/lib/cuba_api/config.rb
which does implement a configuration with inheritance on class level:
Cuba.plugin CubaApi::Config
Cuba[ :state ] = Proc.new { "ok" }
class A < Cuba; end
and the value of can be changed later and A will see the change as well.
Cuba.plugin CubaApi::Config
Cuba[ :state ] = "ok"
Cuba.settings[ :state ] = "ok"
class A < Cuba; end
Cuba[ :state ] = "not-ok"
Cuba.settings[ :state ] = "not-ok"
p A[:state]
> "not-ok"
p A.settings[:state]
> "ok"
making a deep copy during class instantiation is also tricky since order of when the class gets defined does matter.
class A < Cuba; end
Cuba.settings[ :state ] = "ok"
class B < Cuba; end
p A.settings[:state]
> nil
p B.settings[:state]
> "ok"
although A and B are essentially the same class but were defined at different states of Cuba. having those A and B in their own files and require them makes it even harder to understand what is going on
require 'a'
Cuba.settings[ :state ] = "ok"
require 'b'
p A.settings[:state]
> nil
p B.settings[:state]
> "ok"
again using the cuby_api/config plugin makes the code more intuitive.
require 'a'
Cuba[ :state ] = "ok"
require 'b'
p A[:state]
> "ok"
p B[:state]
> "ok"
since intuition varies from person to person I would like to know other opinions.
BTW I would happy to prepare pull request to get something like cuby_api/config into Cuba and deprecate the current settings.
finally need to mention that I do like this little cuba framework a lot - I am about to switch my rails-api server to cuba/cuba_api and the new setup is so much easier to understand. I can understand the whole lot (including cuba) by reading half an hour code.