What is the preferred way (better style) to name a namespace in Ruby? Singular or Plural?

Question

What are for you the pros and cons of using:

FooLib::Plugins
FooLib::Plugins::Bar

vs.

FooLib::Plugin
FooLib::Plugin::Bar

naming conventions? And what would you use or what are you using? What is more commonly used in the comunity?

By looking at [Rails API](http://api.rubyonrails.org/classes/ActiveRecord.html), I see there are more plural names on modules than in classes (see namespaces, at page's second half). However, I don't have enough experience with Rails to get when to use one and when to use the other. — Sony Santos, Feb 15 '12 at 18:16

score 26 · Answer 1 · answered Oct 12 '12 at 10:08

Use:

module FooLib end
module FooLib::Plugins end
class  FooLib::Plugins::Plugin; end #the base for plugins
class  FooLib::Plugins::Bar < FooLib::Plugins::Plugin; end
class  FooLib::Plugins::Bar2 < FooLib::Plugins::Plugin; end

or in a different words:

module FooLib
  module Plugins
    class Plugin; end #the base for plugins
    class Bar < Plugin; end
    class Bar2 < Plugin; end
  end
end

Also arrange the files like this:

- foo_lib/
  - plugins/
    - plugin.rb
    - bar.rb
    - bar2.rb

This is how Rails does it (so this is the Rails Way). I.e. look at the Associations namespace and the Associations::Association class from which all of the classes form the Associations namespace inherits (i.e. Associations::SingularAssociation).

Alex D · Answer 2 · 2012-02-15T13:02:56.857

14

To me FooLib::Plugins appears like a module, used as a namespace which various plugin classes are kept in. FooLib::Plugin looks like a superclass for FooLib plugins.

In FooLib::Plugins::Bar, Bar definitely seems like the name of a plugin. With FooLib::Plugin::Bar, I would be doubtful whether Bar was a helper class used by Foo::Plugin, or the name of a plugin.

edited Feb 15 '12 at 13:02

answered Feb 15 '12 at 12:16

Alex D

29,755
7
80
126

This is a general question. Not attached to what I'm doing. I have some thoughts on this topic and I wanted to see what others think about it all. – Szymon Jeż Feb 15 '12 at 12:23
What about FooLib::Plugins::Bar vs FooLib::Plugin::Bar? - the second looks to me more like an object name -> Bar is a Plugin in the FooLib, the first fits less this reasoning. – Szymon Jeż Feb 15 '12 at 12:27
1

I personally use `FooLib::Plugin` as the superclass of plugins, and also keep all subclasses under it: `class FooLib::Plugin::Bar < FooLib::Plugin`. It feels natural to read: `Bar` is a `Plugin` in `FooLib`. I think a general class containing its specific subclasses in its own namespace makes a lot of sense. I use this nesting system in all of my code. – Matheus Moreira Feb 15 '12 at 17:02

score 4 · Answer 3 · edited Feb 15 '12 at 18:05

Assuming Plugin is a base class:

class FooLib::Plugin::Bar < FooLib::Plugin

This is the one I use and recommend. Bar is a Plugin in FooLib and it inherits from FooLib::Plugin. It also keeps the plugins provided by the FooLib library nested under the namespace of the general class, which reads naturally:
```
# Assign the Bar Plugin of the FooLib library to p.
p = FooLib::Plugin::Bar
```
If I were to develop a third party plugin for your library, I would create the following structure:
```
# Baz is a Plugin for the FooLib library provided by BarLib.
class BarLib::FooLib::Plugin::Baz < ::FooLib::Plugin
```
Note that I mirror the FooLib hierarchy, but under BarLib's namespace. I would not extend it directly.
class FooLib::Plugins::Bar < FooLib::Plugin

I have also used this one, and I think it makes the most sense. Bar extends FooLib::Plugin and is one of the Plugins provided by FooLib. However, it creates a potentially needless module.

I think this would be a great choice if Plugins was a central plugin repository that implements methods like Plugins.add, Plugins.all and Plugins.loaded.

Use it if you can justify the extra module.
class FooLib::Plugins::Bar < FooLib::Plugins

Doesn't make a lot of sense to me. Bar is one of the Plugins in FooLib, that part looks fine. However, it inherits from Plugins. Is it inheriting from more than one plugin? It sounds strange to me; the class name shouldn't suggest something that is impossible.

Many good points made, +1. If the plugins don't inherit from a common base class, `FooLib::Plugins` seems very attractive. — Alex D, Feb 15 '12 at 18:06

score 2 · Answer 4 · edited Nov 05 '13 at 15:28

I would second the approach outlined by @jtrim.

Given that the module (i.e. Plugin) is being used for namespacing only, I typically override the new method in the module:

module Foo
  module Plugin

    def self.included(base)
      raise "cannot be included"
    end

    def self.extended(base)
      raise "cannot extend"
    end

    def self.new(*args)
      Base.new(*args)
    end

    class Base;end
  end
end


base_plugin_obj = Foo::Plugin.new(...)

score 1 · Answer 5 · answered May 31 '12 at 22:10

Generally, the approach I tend to take is:

module Foo
  module Plugin
    class Base; end
  end
end

class Foo::Plugin::Bar < Foo::Plugin::Base; end

The Base class for plugins is a convention found all over the place in the RubyOnRails codebase as well as many others. (e.g. ActiveRecord::Base, ActionController::Base, etc.)

I disagree with @Matheus Moreira's approach where Foo::Plugin is used both as the base class and the namespace for plugins.

The only functional reason why this shouldn't be done has to do with convention - in the Ruby community one will find many less instances of classes as namespaces than modules. The only time I really see classes used as a namespace for another class is when the purpose of said class is private to the namespace class and is not used externally.

What is the preferred way (better style) to name a namespace in Ruby? Singular or Plural?

5 Answers5

Linked