3 ms·

Porting the Rails Inflector to Lisp

12 points by sgrove 16y ago

mcantor 16y ago
Ahhh, the Rails inflector. An entire library dedicated solely to making things less explicit, more magical and more confusing.
- sgrove 16y ago
  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 16y ago
    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. :-/
daxelrod 16y ago
May I suggest you instead model your inflector's algorithm after Lingua::EN::Inflect? ( http://search.cpan.org/perldoc?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.html http://www.csse.monash.edu.au/~damian/papers/HTML/Plurals.ht... 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 16y ago
  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 16y ago
    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.

12 points by sgrove 16y ago

Ahhh, the Rails inflector. An entire library dedicated solely to making things less explicit, more magical and more confusing.

sgrove 16y ago
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 16y ago
  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. :-/

daxelrod 16y ago

May I suggest you instead model your inflector's algorithm after Lingua::EN::Inflect? ( http://search.cpan.org/perldoc?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.html http://www.csse.monash.edu.au/~damian/papers/HTML/Plurals.ht... 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 16y ago
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 16y ago
  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.