Topic: I just can't accept pluralization!

I've tried -- I've really tried -- to see the virtue in having my code pluralize and unpluralize and re-re-pluralize my identifiers. I just can't seem to enjoy that sort of thing.

Every time I generate a new Rails project, I promptly put this code into my inflector:

# Turn off all pluralization in both directions.
Inflector.inflections do |inflect|
  inflect.plural /^(.*)$/, '\1'    # Plural of anything is itself
  inflect.singular /^(.*)$/, '\1'  # Singular of anything is itself
end

I love Rails.

But it's an abusive love. All because of Rails' compulsive pluralization predilection. I just want to have my identifiers stay right where I put them! It makes me sob with despair when my productivity tools are so needy. I hate Microsoft Clippy, and not just because he's got the stink of Gates on him ("You seem to be trying to accomplish something...").

Natural languages are for artfully conveying meaning among humans. Programming languages are for precisely controlling logic machines. Why is Rails trying to make my code somewhat grammatically correct some of the time? It'd be one thing if I were allowed to mix and match singulars and plurals at will. That would be easier on Rails developers and Rails users alike. Even I would welcome such a feature. But instead, my code breaks when the plurality is incorrect. Plus, some parts of Rails choke on fish!

Can someone please explain to me some advantage to having my identifiers shift under my feet like this? It creeps me out, and makes me feel dirty.

Help!

Re: I just can't accept pluralization!

Pluralization is wonderful.. embrace it and say goodbye to your pain!

http://agilewebdevelopment.com/plugins/ … od_speeler

Re: I just can't accept pluralization!

That plugin seems to be intended to make the inflector more linguistically reliable with irregular English-language words. That's not what I'm asking for here. My problem is not that the inflector singularizes daves as dafe instead of dave. My problem is that I find it distasteful that Rails is trying to force me to submit to pluralization of MY code in the first place.

Can someone please explain to me why I should want Rails to be taking liberties with my identifier names? I hate it. I hate it. I hate it.

I prefer this naming convention:
1. All identifiers are singular in every context.
2. That is all.

But maybe there's some secret advantage to having pluralization thrust at me that I haven't yet thought of. So why should I bend over for the Rails inflector? What's in it for me besides wasted brain cycles, wasted CPU cycles, and extra bugs? Unless I hear some compelling reason to WANT pluralization, I just want to flee.

Re: I just can't accept pluralization!

Sometimes you just have to give in to the power of the force.

Re: I just can't accept pluralization!

http://i234.photobucket.com/albums/ee60 … /chill.jpg tongue

Pluralization seems to be one of those things that rails just does. It makes sense to me because if I have a table called 'users' I can show the database diagram to anyone and they can understand that the table holds info about all the users. A table called plain 'user' implies (by english language conventions) that the table has info for just one user.

When I'm in my code and I work with a User object, I'm dealing with one user. Easy.

Like pluralization or not, when was the last time a language or framework did something like this and you could undo it in two lines of code???

Re: I just can't accept pluralization!

Okay, jbartels, I took two of those half-pound chill pills. Thanks.

I'm using Rails because it's good stuff. So instead of giving in to the "power of the force" of PHP or other mediocre web application tools, I'm switching to Rails. But now I'm considering switching to something else. No amount of elegance and simplicity can make up for this pluralization blight.

This pluralization thing is not just a minor annoyance. My code won't run now, because I'm trying to go RESTful.

When I first started using Rails, I just went along with the pluralization regime because I figured it was thought through by people who are smarter than I, and there must be some good reason for it. But after a while, it annoyed me more and more, so i lobotomized my inflictor. Those "two lines of code" were unbelievably liberating. Now I get all the good parts of Rails, that is, everything except mandatory code pluralization, with none of the bad part(s). (I can always pencil in a few 's' marks on the diagrams I show my grandma.)

Everything was back on track until I started going RESTful. Rails RESTful routing appears to rely on each identifier having two distinct spellings for singular and plural forms in order not to fall on it's face. I consider this a bug, not a desirable condition. I can only hope the Rails team would agree that relying on an artifact of the English language in order to keep your code from crashing is a brittle solution.

I don't know how to fix this, so I'm at a standstill. I'm facing a decision to either re-write all my code to be pluralization-compliant (and gargle with mouthwash every time I sit down at my keyboard and submit to this), or abandoning the RESTful services.

On second thought, I will never submit to pluralization. I'd sooner code in PHP.

But  now I'm worried that even if I do get past this RESTful trouble, I'll be hit with more surprises when I've got real Rails applications running. Maybe, now or someday, there's sloppy code deep in the bowels of Action Controller that chokes on fish and sheep.

I'm losing trust in Rails.

Re: I just can't accept pluralization!

Well, one of rails most profund principles is "convention over configuration" - pluralization is just one of the things in rails where this principle gets used.

The reason for it - and the reason i personally love it - is that it makes the code much more readable, and it has a logic behind it that suits my thinking, and obviously that of many others.

you look at code and someone does
@model.people
and you KNOW it will return an array of people objects, you KNOW it is a has_many releationship (except of course, the user tempered with defaults through the options).
Those things are advantages when working together on something, and for myself too, when i look at old code i write a while back.

And with that goodness (from my perspective) i don't see the disadvantages you obviously seem to see.
- if some pluralization doesn't work as expected, add it to the inflector. one line of code
- if you want singular table names, disable table pluralization. one line of code.
- if you want all associations to be singular no matter their type, well, you got a problem, with what i stated above, i dont see the use.

Much of the rest goodness like clean and small code, is only possible because of these assumtions rails does. But if this is a dealbreaker for you, switch to PHP. Pluraization is so deeply build into Rails, that you wont get rid of it everywhere forever. The most important points like table names and stuff can be easily changed through some minimal configuration. if that's not enough, Rails is not for you. Rails is not suitable for everyone, and not for every task or project. Some projects need different concetps or techniques, some people can't adapt to the basic conventions behind Rails. You seem to be one of them, unfortunately.

my 2 cents.

Last edited by Duplex (2008-01-30 15:38:59)

Re: I just can't accept pluralization!

I don't think Rest needs to assume all identifiers have distinct plural and singular spellings. The conflict in there has something to do with the URL names that are generated, not the URLs themselves. I'm not sure about that though, since I'm lacking knowledge about how this stuff stitches together under the surface.

When you generate a RESTful scaffold of an uncountable-word-named model, you get routes like this:

fish_index     GET  /fish             {:controller=>"fish", :action=>"index"}
new_fish       GET  /fish/new         {:controller=>"fish", :action=>"new"}
edit_fish      GET  /fish/:id/edit    {:controller=>"fish", :action=>"edit"}
fish           GET  /fish/:id         {:controller=>"fish", :action=>"show"}

Pluralizing-word-named models get this:
carps          GET  /carps            {:controller=>"carps", :action=>"index"}
new_carp       GET  /carps/new        {:controller=>"carps", :action=>"new"}
edit_carp      GET  /carps/:id/edit   {:controller=>"carps", :action=>"edit"}
carp           GET  /carps/:id        {:controller=>"carps", :action=>"show"}

I'm baffled as to why it's not something that's consistent, non-subtle, and works every time no matter what? Something like this:
index_fish     GET  /fish             {:controller=>"fish", :action=>"index"}
new_fish       GET  /fish/new         {:controller=>"fish", :action=>"new"}
edit_fish      GET  /fish/:id/edit    {:controller=>"fish", :action=>"edit"}
show_fish      GET  /fish/:id         {:controller=>"fish", :action=>"show"}
(Or perhaps, fish_index, fish_new, fish_edit, etc.)

Similarly, person_instance, person_model, and person_collection are no harder to decipher than person, person, and people. All I ask is that Rails not crash when I try to write code that's less confusing for me. Fortunately for me, I program in the English language, which features a few nouns that are spelled the same in plural and singular. Which means there's an implicit obligation to support my coding style.

The rationale that says a data model must always be called "person" because it represents the shape of a single database record, while a collection of this model must always be called "people" because it is (usually) some length other than 1, is without merit in my view. Because if all models are singular and all collections of those models are plural, then why bother with two separate spellings for the identifier? Whatever meaning is embodied in the plurality of the word is also embodied in the context of its usage. That is, no human would ever be confused reading about a "person collection" vs. a "people collection". But if my code crashes -- or worse, doesn't crash -- when it has the wrong plurality of a word, that's a Bad Thing. And when you build complex constructs of plurals of singulars of plurals, it gets pretty bizarre to puzzle through this stuff, for no apparent payoff.

If rails were just another piece of "something", I wouldn't sweat it, and drop it. It's just so agonizing to come so close to what I want, and have it snatched away by such a seeming triviality.

But I really do want to hear some reasons why pluralization is a Good Thing.

That @model.people example of Duplex is a good start. I've never seen quite that syntax before, so I don't know if you'd ever have a @model.person alongside it in pluralization-compliant Rails code. If both forms (@model.people and @model.person) would reasonably occur in real code, and they make things possible that otherwise wouldn't have been, then maybe there's something to this pluralization business. (I've gotta figure out what @model.people does. I'm new to Rails.)

Please let me know all your favorite advantages of code pluralization.

Re: I just can't accept pluralization!

Oops. My mistake, @model is meant to be an ordinary instance variable. I guess I have seen that exotic syntax from time to time. (blushing)

So what can I actually get done using dynamically pluralizing attributes in Rails that's inconvenient or impossible with plain old boring, always-the-same-name attributes?

Re: I just can't accept pluralization!

While it is rare to have @person and @people in the same template, the relationships between your models are greatly affected by pluralizing. Like duplex pointed out

@company.people will show all the people from a given company and reflects a has_many relationship
@company.person reflects a has_one or belongs_to association

All of this stuff is deeply engrained in Rails, not just in your views
but in your models as well

[code =ruby]class Person < ActiveRecord::Base
  belongs_to :company
end

class Company < ActiveRecord::Base
  has_many :people
end

class Company < ActiveRecord::Base
  has_one :person
end[/code]

Why on earth would you want to say has_many :person?

Rails is opinionated software and pluralization is an innate part of the structure for a reason.

I fought a lot of these conventions at first because I didnt understand, but once you see the big picture

you start to appreciate the choices Rails has made for you.

If it still bothers you that much, then maybe RoR just isnt your cup of tea.

Re: I just can't accept pluralization!

All I'm saying is that Rails shouldn't get Alzheimer's disease if I choose to turn off pluralization. It usually does just fine with singulars and plurals that happen to be spelled the same. But the RESTful routing seems to work for a while and then crash. If this is meant to punish people who don't play the plurals game, it's plain creepy. I like to think of it as a bug.

Suppose I've got a table called rj204x. Why should I have half my identifiers be rj204xs? Suppose I want to code Rails in a natural language that has a plural form denoting zero, one, two, a few, and many (such languages do exist). How should the inflector respond? Or maybe I want to use a language that has a single form for all words in all contexts (no plurals, no genders, no tenses, etc.) Chinese conveys such information entirely through context. If you're talking about non-one of female puppy-dogs in the past, you just say so! Or maybe I just like having all my identifiers stay the same everywhere in my code, so they're searchable and consistent.

> Why on earth would you want to say has_many :person?

Because 'person' would be the name of the database table, the model, the relational reference field (in either direction), the cache counters, and the class of any object representing any data of that type. It seems only natural that I'd want the ORM association to declare a relationship to it as well.

Reading this code into English as, "Each Company has_many :people," may be kinda grammatically correct, but it's factually inaccurate. After all, we're not talking about an actual company and actual people, only some data about them. Reading it as, "Each Company model object may be referenced by any number of Person model objects," while being perfectly accurate, is no less grammatically correct. The 'has_many' method carries a specific meaning that we all know. The symbol it receives as a parameter is just that -- a symbol.

So far, these are the advantages to code pluralization that I've picked up on from this discussion:

1. The code is somewhat more grammatically correct when read as a kind of pidgin English.

2. A plural identifier denotes an array, while a singular denotes an individual item.

I see no merit to number one. Number two, however, does carry some value. It's nice to see the difference between a model object and a collection of those model objects in the code, even if that code is written by a sloppy programmer who doesn't bother to sensibly name their variables or properly comment. But what's the value of those advantages, and do they justify the costs? It seems most people around here would say they do. I disagree.

But we don't have to force agreement about this. Rails can, and usually does accommodate my needs. As Jbartels says, "Like pluralization or not, when was the last time a language or framework did something like this and you could undo it in two lines of code???"

If only this were as true of RESTful routes as it is of the rest of Rails.

Re: I just can't accept pluralization!

Regarding the comment that "A plural identifier denotes an array, while a singular denotes an individual item."

If it is so important to identify type through variable names, shouldn't we all be using Hungarian notation?

Toby Hede
===================================================
FiniteStateMachine - Software Development for Social Networks
===================================================