Why do I see includes often named with the suffix "able" in model files?

rubyonrails-talk
1

Why do I see includes often named with the suffix “able”? Is this a naming convention that’s being utilized? I also see other variations being used, such as “ed”, but mostly it seems to be “able”. I’m currently refactoring code and would like to understand this more so I can possibly adopt the approach in my own projects.

An example is the following from @dhh in his new videos he’s been posting on Youtube here.

class MessagesController < ApplicationController include SetRecordable, BucketScoped

…

end

``

Thanks!

2

I believe suffix is generally used when you’re using polymorphic associations (for example, you may have Comment model that belongs_to :commentable). In DHH’s video, I believe it’s the case, because recordable is most likely used for variety of models in BC3.

3

Yes. It's used to denote that you're including a module that adds behavior/data/whatever to a class, such that you can do whatever to its instances -- i.e., they are whateverable. It's particularly useful when you want to explicitly duck-type a parameter or association (primarily polymorphic).

For instance, suppose you wish you could gribbulate (made-up verb) instances of some large number of classes, possibly even unrelated. They'd need to have some specific data and/or behavior added, like a #gribbulate! method, accessor for its gribbulator, enumerated gribbulation type, default but overridable gribbulation response (something custom for it to do after being gribbulated), etc. You can add that code to all those classes manually, or stick that in a module for these various classes to include. By convention, such a module would be called Gribbulatable.

Then, suppose you also have class Gribbulator. Many of its methods will ass-u-me that their main parameter is a Gribbulatable. Having module Gribbulatable makes it easy for you to construct objects suitable for feeding to a Gribbulator.

And if you want to keep track of when each Gribbulatable was gribbulated, you might have class Gribbulation to keep track of which Gribbulator gribbulated which Gribbulatable, and when. It will hold a reference to a Gribbulatable, as a polymorphic association if you have multiple Gribbulatable classes. (In addition to a presumably non-polymorphic one to the correct Gribbulator.)

Unlike a lot of Rails "magic", though, I don't think anything depends on adhering to this convention.