Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel.const_set, seriously? #122

Closed
quaternion opened this issue Dec 10, 2015 · 6 comments
Closed

Kernel.const_set, seriously? #122

quaternion opened this issue Dec 10, 2015 · 6 comments
Milestone

Comments

@quaternion
Copy link

The Kernel module is included by class Object, so its methods are available in every Ruby object.

Result:

Module::Settings #=> #<Config::Options ... >
Class::Settings #=> #<Config::Options ... >
nil::Settings #=> #<Config::Options ... >
ActiveRecord::Base::Settings #=> #<Config::Options ... >
@pkuczynski
Copy link
Member

How would you suggest to implement it differently?

@malakai97
Copy link

Anyone who needs this to be loaded into the global namespace by another name should just do it themselves. It's a trivial assignment.

require "config"
MySettings = Config

I suggest removing this feature.

@quaternion
Copy link
Author

Through definition a custom class or module:

class Settings < Config::Base
end

or

class Settings
  include Config
end

@pkuczynski
Copy link
Member

You are totally right that Kernel.const_set is not the best way to expose settings. This was in the code, before I joined the project and I never really thought about it before... There are couple of problems with the current setup actually. First of all Config is a module which holds the logic of loading settings, while what you referring to is a static OpenStruct object called Settings, holding all the values for settings - so they two different things and neither of the solutions you described above would work.

I actually never liked this split and always thought it should be a single object. Additionally its confusing with config as a gem name and object used to wire things up, while actually values are accessed via Settings instance. Config also conflicts with some old object name and raise a warning...

I do not have anything fixed in mind how to solve this, as I assume original gem author wanted to keep Settings slim...

I will have to think about it... Any suggestions welcome...

@baarde
Copy link

baarde commented Jul 11, 2018

Regarding the problem of exposing Settings in every module, I think you can fix that by replacing Kernel with Object.

irb(main):001:0> One = 1
=> 1
irb(main):002:0> ::One
=> 1
irb(main):003:0> Object::One
=> 1
irb(main):004:0> ActiveRecord::Base::One
Traceback (most recent call last):
        1: from (irb):4
NameError (uninitialized constant ActiveRecord::Base::One)
irb(main):005:0> 
irb(main):006:0> Object.const_set 'Two', 2
=> 2
irb(main):007:0> ::Two
=> 2
irb(main):008:0> Object::Two
=> 2
irb(main):009:0> ActiveRecord::Base::Two
Traceback (most recent call last):
        1: from (irb):9
NameError (uninitialized constant ActiveRecord::Base::Two)
irb(main):010:0> 

See Stack Overflow: Ruby, how to reference Root namespace?

@pkuczynski
Copy link
Member

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants