can_has_stats ftw!

@Adam – That was both a hilarious and insightful comment (could be an article in of itself!). Where are my slashdot moderation points when I need them? I think you hit the naming scheme spot on… I couldn’t have said it better myself!

I’ll be honest, I’m a little afraid of chuck_norris_fu right about now. I have to wonder though… chuck_norris_fu still seems impossible. The only thing powerful enough to describe Chuck Norris is the voice of Chuck Norris. Surely Ruby would fall to its knees, begging for mercy, if it ever attempted to describe that which is Chuck Norris.

Unrelated to Chuck Norris, I think what finally made me go psycho were things like acts_as_commentable, acts_as_rateable, acts_as_emailable, etc… the list goes on and only seemed to get worse. It’s at that point I started migrating toward a has_* or just * naming scheme. For example, I moved to has_comments, has_ratings, has_emails, which actually matches the definition exactly as you provide. Instead of acts_as_state_machine, I have just state_machine.

Someone should definitely create a plugin name generator script that’ll figure out what prefix/suffix to use based on a couple of input parameters That would be amazing. Any takers?

I still don’t think I’m a fan of *_fu or *_jitsu, though. Why is it called attachment_fu and not just has_attachment? That’s probably a bad example of using the _fu suffix, but it feels like a stretch.

The trick is to agree upon what the tags mean. If we come to that agreement, then we can merrily go on our way renaming things where necessary. I think that there are 4 mutually independent tags for us to consider, all of which you’ve seen:

acts_as_* — I think that the best examples of this are acts_as_tree and acts_as_named_set, at least for establishing the meaning of the tag. I would suggest that the * in acts_as_* describes the models as a collection. That is when I say:

class Page < ActiveRecord::Base
acts_as_tree
end

I can say that a collection of Pages is a tree and each Page is a node in that tree. I if I wanted to be pedantic about it (and Rails is opinionated, so why not) I could go further and require that acts_as_* applies to collection of ALL pages (that is there my be only one root node) and that if want all the pages to form a number of trees, I need to use acts_as_trees or acts_as_forrest.

So that’s my test: if I can say that the collection of all my models is a Foo then acts_as_foo is the correct name.

By this standard, the geokit acts_as_mappable is wrongly named; the collection of all my mappable models is not “a Mappable”

*_fu — First of all, the actual tag name, might be better if it was something other than _fu, but I like the whimsy and I’m bad at picking helpful names. I’m not sure that this definition is in current use but the heading “chuck_norris_fu consists of one move: the roundhouse kick” illustrates how I would use it. Associating something’s _fu with a model is to impart that things properties upon the model. So (continuing with the whimsy) if I have

class TexasRanger < ActiveRecord:Base
chuck_norris_fu
end

Then each ranger (as an individual) is capable of delivering a Chuck Norris roundhouse. Note that they are not Chuck Norris, rather they are are merely channeling Chuck Norris. As a result if two of them fought and used the roundhouse kick at the same time, it would merely result in the immediate conversion of all matter within an infinite radius into energy (Chuck Norris fighting himself would actually cause the universe itself to cease to exist).

With this description, GeoKit would have geolocation_fu.

*_jitsu — Is like _fu but it applies at the class level just like acts_as_*. I’m having a harder time with examples but I think I have one. In Radiant, there is a class Radiant::Config < ActiveRecord:Base. Since config values are just name/value pairs it allows you to do things like puts Radiant::Config["my_key"] and Radiant::Config["my_key"] = “some new value”. I might decide that this would be a generally useful thing to do so I’m going to create a plugin to do this. I would call it something like configuration_jitsu.

has_* — I don’t get the can_ part of can_has_*, would you also have must_has_*)? This is trivial. If there is something special about how a particular association works then it gets a unique has_* method. For example, attachment_fu works with my scheme above so you might create has_attachment to handle that particular polymorphic situation easily.

I think these are reasonable “rules” for naming. Many things don’t fit into the scheme (like auto_validation) but that’s ok

long live can_has_*

@Wynn – I definitely agree that there are acts_as_* plugins that make sense at times .. but more than 1/2 the time I think it’s a stretch. It’s sort of become convention to use that prefix for plugins focused on model extensions, but does that indicate a failure in us being able to properly categorize plugins? You don’t tend to see that with something like WordPress plugins.

@Zack – I was surprised to see that someone had actually already created acts_as_fu

@adam – I am in complete agreement with you and my thoughts on that matter can span several blog posts. I get a lot of people asking me the exact same question. I feel it was a complete mistake to invent something called a “plugin” that didn’t just mean gems meant for extending Rails. As far as I’m concerned, I release them both as a “plugin” and a gem, so people can use it in any way they like.