settings can not use all objects when having a subclass and . . . #21
Comments
|
Got the same "problem". Consider following example: require 'cuba'
require 'cuba/render'
require 'erb'
class TestController < Cuba
define do
on root do
res.write view("home")
end
end
end
# TestController is in own file (controllers/test_controller.rb)
# Dir['controllers/*.rb'].each { |file| require |file|
Cuba.plugin Cuba::Render
Cuba.define do
on root do
run TestController
end
end
run CubaThis results in If I require / define my controller after |
…an#21) This fixes an issue where settings added to Cuba.settings *after* inheriting from `Cuba` are not picked up by the child classes. The issue is described in issue Settings are lookup up in the settings Hash of the parent class if a setting does not exist using `Hash#default_proc`. The settings Hash is still deepcloned, so they're still overridable.
…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.
|
I think we have two issues here: one is the fact that by using I don't know a solution for the first problem. If the settings are not copied, the risk is that a child class could modify a setting in a parent class. By using About the second problem, I think we can do better if we determine that the order in which the settings are defined should not determine which settings are copied. I have already an implementation that solves that problem, so all we need to do is to think hard and decide which would be the proper behavior: do we want the settings to be a snapshot of the parent's settings at the moment of subclassing, or we want the settings to be copied at the time of reading them in the child class? @mkristian @tak1n I'd love to read your comments about this. |
|
Just curious about this. Any update on how to inherit the settings? I see settings as a part of a booting or setup step where we set Cuba settings in the beginning. |
|
@soveran I think taking a copy at the moment of subclassing is cleanest. It would avoid situations where a cuba app tries to use a setting that isn't guaranteed to be there. Consider the following: a.rb class A < Cuba
define do
on(default) { a.settings[:foo].upcase }
end
end
**b.rb**
```ruby
require "a"
class B < A
define do
on(default) { A.settings[:foo] }
end
endapp.rb require "b"
A.settings[:foo] = "only now defined"
Cuba.define do
on("a") { run A }
on("b") { run B }
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:
and the value of can be changed later and A will see the change as well.
making a deep copy during class instantiation is also tricky since order of when the class gets defined does matter.
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
again using the cuby_api/config plugin makes the code more intuitive.
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.
The text was updated successfully, but these errors were encountered: