![\"\"](\"https:\/\/pbs.twimg.com\/profile_images\/669251313016770560\/EE3-bufl.jpg\")
<\/p>\n<\/p>\n
This is a guest post by\u00a0Junichi Ito (@jnchito<\/a>).\u00a0<\/em>Junichi is a Ruby programmer at SonicGarden.jp<\/a>, translator of Everyday Rails Testing with RSpec, and\u00a0one of the most popular Ruby writers\/bloggers in Japan<\/em><\/p>\n If you use a class as a namespace, it can produce a bug that doesn’t always show up on the surface. You should different names for your model class and your namespace in Rails applications.<\/p>\n <\/p>\n You can use both classes and modules as a namespace. But if you use a class, it might lead to unexpected behavior, especially in Rails applications. You want to create two pages, one is for end users and the other is for staffs. End users can see published items only, but staffs can see all items. Then, you create these two controllers:<\/p>\n But For an explanation, I’ll use a simpler example. If you run the code below in irb, you can refer to You can see that However, when When the application is run, sometimes This problem can also occur in Rails applications. When you run To avoid this problem, you should use different names for your model class and your namespace, for example, If When the namespace is a module, the constant lookup leads to different results from the class namespace, because the module does not have ancestors other than itself. Let us see the results in irb:<\/p>\n This time, In irb The top-level constant lookup rule in Ruby might be changed in a future version, because the topic “remove top-level constant lookup” is being discussed here:<\/p>\nTL;DR<\/h3>\n
class Staff < ApplicationRecord\r\nend\r\n\r\n# Shoud not use class as namespace\r\nclass Staff::ItemsController < ApplicationController\r\nend\r\n\r\n# Should use a different name for namespace\r\nclass Staffs::ItemsController < ApplicationController\r\nend<\/pre>\n
Hidden bug with a class name as a namespace<\/h3>\n
\nFor example, you have two classes called Item and Staff:<\/p>\nclass Item < ApplicationRecord\r\n scope :published, -> { where(published: true) }\r\nend\r\n\r\nclass Staff < ApplicationRecord\r\nend<\/pre>\nclass ItemsController < ApplicationController\r\n def index\r\n @items = Item.published\r\n end\r\nend\r\n\r\nclass Staff::ItemsController < ApplicationController\r\n def index\r\n @items = Item.all\r\n end\r\nend<\/pre>\n
Staff::ItemsController<\/code> sometimes works wrong. It might return only published items. Why? This problem is related to Ruby’s constant lookup rule.<\/p>\nStaff::ItemsController<\/code> without definition:<\/p>\nclass Item; end\r\nclass Staff; end\r\nclass ItemsController; end\r\n# Refer to Staff::ItemsController without definition\r\nStaff::ItemsController\r\n# warning: toplevel constant ItemsController referenced by Staff::ItemsController\r\n#=> ItemsController<\/pre>\n
Staff::ItemsController<\/code> returns ItemsController<\/code>. Here\u2019s why:<\/p>\n\n
Object<\/code> class, so ItemsController<\/code> is equal to Object::ItemsController<\/code>.<\/li>\nStaff::ItemsController<\/code> is referred to, Ruby cannot find the constant ItemsController<\/code> in the Staff<\/code> class. Then, Ruby tries to find it from the Staff<\/code> class’s ancestors.<\/li>\nStaff.ancestors<\/code>. It returns [Staff, Object, Kernel, BasicObject]<\/code> in the sample code above.<\/li>\nItemsController<\/code> in the Object<\/code> class which is next to the Staff<\/code> class in the ancestors array. Does the Object<\/code> class have ItemsController<\/code>? Yes, Ruby could find ItemsController<\/code> successfully, because Object::ItemsController<\/code> is already defined.<\/li>\nStaff::ItemsController<\/code> is already defined, Staff::ItemsController<\/code> can be referred to not by ItemsController<\/code>, but by Staff::ItemsController<\/code> because Ruby can find ItemsController<\/code> in the Staff<\/code> class:<\/p>\nclass Item; end\r\nclass Staff; end\r\nclass ItemsController; end\r\nclass Staff::ItemsController; end\r\n\r\n# Refer Staff::ItemsController after definition\r\nStaff::ItemsController\r\n#=> Staff::ItemsController<\/pre>\n
Staff::ItemsController<\/code> can be referred to after definition and sometimes referred to before definition. The former leads to expected behavior and the latter leads to unexpected behavior. This is the hidden bug.<\/p>\nStaff.ancestors<\/code> in the rails console, you can see a lot of classes and modules. But the Object<\/code> class does exist in ancestors. So this means that Staff::ItemsController<\/code> can refer to Object::ItemsController<\/code> when Staff::ItemsController<\/code> is not defined.<\/p>\nUse different names for your model class and your namespace<\/h3>\n
Staffs::ItemsController<\/code>.<\/p>\nStaffs::ItemsController<\/code> is defined in the app\/controllers\/staffs<\/code> directory and the constant Staffs<\/code> is not defined yet, Rails defines the Staffs<\/code> module automatically. (This function is called “Automatic Modules”. Please see Rails Guides<\/a> for details.)<\/p>\nclass Item; end\r\nclass Staff; end\r\nclass ItemsController; end\r\nmodule Staffs; end\r\n\r\n# Confirm Staffs module's ancestors\r\nStaffs.ancestors\r\n#=> [Staffs]\r\n\r\n# Refer to Staff::ItemsController without definition\r\nStaffs::ItemsController\r\n#=> NameError: uninitialized constant Staffs::ItemsController\r\n# Did you mean? ItemsController\r\n# from (irb):6\r\n# from \/Users\/jit\/.rbenv\/versions\/2.4.0\/bin\/irb:11:in `<main>'<\/pre>\n
Staffs::ItemsController<\/code> was considered to be an uninitialized constant. This is because the Staffsmodule<\/code> does not have Object<\/code> in its ancestors. So Ruby won’t look up Object::ItemsController<\/code> and the constant lookup fails.<\/p>\nRails can load Staffs::ItemsController without errors<\/h3>\n
Staffs::ItemsController<\/code> is an uninitialized constant and Ruby produces an error, but this scenario is different in Rails applications. Rails implements the const_missing hook and tries to find Staffs::ItemsController<\/code> in autoload_paths<\/code>. If Staffs::ItemsController<\/code> is defined in autoload_paths like app\/controllers\/staffs\/<\/code>, Rails can load Staffs::ItemsController<\/code> without any errors. Please see Autoloading and Reloading Constants<\/a> in Rails Guides for details.<\/p>\nNOTE: The problem described in this post might be fixed in the future<\/h3>\n