

Porting the Rails Inflector to Lisp - sgrove
http://trapm.com/vana-inflector-an-english-inflector-in-common

======
daxelrod
May I suggest you instead model your inflector's algorithm after
Lingua::EN::Inflect? ( <http://search.cpan.org/perldoc?Lingua::EN::Inflect> )
It handles tons of cases better than Rails's inflector does.

Damian Conway (Lingua::EN::Inflect's author) also wrote a paper about
algorithmic English pluralization that actually takes a linguistic approach to
all of this:
[http://www.csse.monash.edu.au/~damian/papers/HTML/Plurals.ht...](http://www.csse.monash.edu.au/~damian/papers/HTML/Plurals.html)

The hard part about an inflector as part of something like a framework is that
it's hard to add special cases later when you need corrections, because you
risk breaking the existing incorrectly pluralized or singularized names people
have for things. It's much easier to get it as right as possible as soon as
possible.

~~~
sgrove
That's an insane library - I'll definitely take a look at it. This was just
meant to be a reasonable stop-gap as I start to build real tools, but you
raise some good points. I've book marked the Lingua::EM::Inflect to revisit
for porting later - thanks!

~~~
daxelrod
To be fair, I've never looked at the source until now and... wow. I'm
definitely glad he wrote the paper to go along with it.

It's not even that most of the code is hard to read (although a few parts did
leave me scratching my head), it's just that without the lingustic
explanations I'd be lost.

I wouldn't blame you if you held off porting it for the time being. A stopgap
measure is definitely better than nothing. I just wanted to make sure you knew
about it.

------
mcantor
Ahhh, the Rails inflector. An entire library dedicated solely to making things
_less_ explicit, _more_ magical and more confusing.

~~~
sgrove
Oh? I'm curious as to what you mean. I can imagine the CamelCase to camel_case
bit that's used for a lot of the internal class/file-naming stuff might fit
your description, but certainly not the singularize and pluralize methods.

~~~
mcantor
I don't really have a huge problem with it. I dislike Rails in general because
it's a 500-pound gorilla that people use instead of understanding what's
actually going on in their app, and I'm frustrated that it's the first point
of contact most people have with Ruby. Rails has a lot of sorcery in its code,
which is trivially exemplified[1] by the inflector, and Ruby doesn't have to
be that way.

For example, let's say you have a Big Giant App with fifty database tables,
each with a corresponding model object. You can use the Rails inflector, which
is God-knows-how-many lines of code by now. Or, you can have a 50-line file
that looks like this:

    
    
      model_table_map = {
        User => 'users',
        Shark => 'sharks',
        Lazer => 'lazers',
        Antenna => 'antennae',
        ...
        Locus => 'loci',
        Species => 'species'
      }
    

(Don't ask me what kind of screwed up, terrifying app you could possibly be
writing that requires these classes, 'cause I don't know!)

This has numerous advantages over using the Inflector:

\- The conversion from singular class name to plural table name is
_unambiguous_ and _self-documenting_ , so if you come back to the code in 6
months, or if you are working with someone for whom English is not their
primary language, you don't have to wonder, "Hmmm... is 'locus' one of those
words with an irregular plural inflection? If so, does the Inflector know
about it?"

\- It's one less dependency you need to trust.

\- Memoization makes this already-minuscule point nearly moot, but calling
model_table_map[obj.class] is faster than inflecting it.

Like I said: It's really not a big deal, and probably counts more towards
personal preference than anything else. I simply prefer to be as explicit as
possible until it would simply _hurt less_ to use magic.

 _"Design is the successive application of constraints until only a unique
product is left."_ \- Donald Norman, The Design of Everyday Things

1\. Can something non-trivial be _trivially_ exemplified? I dunno. :-/

