silkapp / rest

Packages for defining APIs, running them, generating client code and documentation.
http://silkapp.github.io/rest
390 stars 52 forks source link

Properly pluralize resource names #85

Open MichaelXavier opened 9 years ago

MichaelXavier commented 9 years ago

Ran into a minor issue. I use the plural naming of resources (posts, comments). The view was doubly pluralizing them (postss, commentss) and I didn't see an easy way to change this behavior in user space. This adds the Plural dependency, which brings in regex-tdfa, but it is not version bound and requires no external deps, so at worst this should just slow down compile time by a few seconds.

bergmark commented 9 years ago

This only affects documentation, correct?

bergmark commented 9 years ago

I'm hesitant of accepting this as is. Plural has not been updated since 2009, has no upper bounds (I consider this a bad thing), is licensed as GPL, pulls in a new dependency, and doesn't list a source repository.

Are there other ways to go about this, such as making pluralization optional?

MichaelXavier commented 9 years ago

This is indeed a documentation change, but that's half the reason why I'm looking at using rest, is to generate up to date docs ;)

I believe the project hasn't been updated since then because its a small problem space and a slowly moving target (the English language). I see 2 alternatives: 1. Make a really dumb, hand-rolled pluralize that appends an S except if the word ends in an S. 2. We could figure out how to make this markup easier for users to customize. Ultimately, I think the second option is right overall but you'd probably know better than me how feasible that is. In the end, this flexibility would be valuable, as you'd eventually want to extend resources with more documentation, kind of like what apiary does.

hesselink commented 9 years ago

Another option is to write our own package. We could steal a word list from somewhere (e.g. rails, and the code should be pretty simple. This would still be low effort (hopefully), doesn't have to be perfect, but is much better than just hardcoding 's'. This would probably also pull in some regex or parsing library but that's fine by me.

At some point we definitely also want extensible documentation (see #54) but I think that's a different (and bigger) project.