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

[David McDonald]

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!

[Rolandas Barysas]

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.

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.

To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/d79cfb72-a87c-4779-b8e6-51e377db7fc1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dave Aronson]

On Thu, Feb 15, 2018 at 8:46 AM, David McDonald <dave...@gmail.com> wrote:

> Why do I see includes often named with the suffix "able"? Is this a naming
> convention that's being utilized?

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.

--
Dave Aronson, Software Development Consultant
T. Rex of Codosaurus, LLC (http://www.Codosaur.us)
What can we evolve for you today?