Make the apply_inflections method case-sensitive #14247
Conversation
|
👍 |
|
@fxn : Would you mind having a look please ? :-) |
| @@ -1,3 +1,8 @@ | |||
| * Make the `apply_inflections` method case-sensitive when checking | |||
There was a problem hiding this comment.
Should not it be case-insensitive now?
There was a problem hiding this comment.
I may be wrong but I think "case-sensitive" is right. At the moment, if we want to make the "HTTP" string uncountable, we'd have to write inflections.uncountable "http" (that would apply to "Http", "HtTp", etc. too) so I'd say that this is case-insensitive currently.
With this patch, half the problem is resolved. Actually if we write inflections.uncountable "HTTP", "HTTP" is defined as an uncountable but "http", "Http", etc. too. There is no easy way to fix this as people may except "Information".pluralize to return "Information" if we have the inflections.uncountable "information rule.
There was a problem hiding this comment.
I think it's now case insensitive in both directions; previously it was insensitive to the case of the string being inflected, but very sensitive (as in, only one worked) to the case when the inflection is defined.
|
We don't want to just |
|
@matthewd if we do that HTTP and HTTp will be the same and I think they should not. |
As I understand it, "HTTP" and "HTTp" are getting treated identically either way: there's only one place we use |
|
Yes, make sense. I think we should store the downcase version |
|
@rafaelfranca @matthewd : Your comments have been addressed normally, thanks for your feedback and sorry it took so long to get a response from my side! :-) I've updated the commit message to reflect the actual performances ; this seems even faster with your suggestion (we are meeting the same performances as it is currently on |
| @@ -160,7 +160,7 @@ def irregular(singular, plural) | |||
| # uncountable 'money', 'information' | |||
| # uncountable %w( money information rice ) | |||
| def uncountable(*words) | |||
| (@uncountables << words).flatten! | |||
| (@uncountables << words.flatten.map(&:downcase)).flatten! | |||
There was a problem hiding this comment.
And since we already call flatten before the map we still need the flatten!?
There was a problem hiding this comment.
As for #map!, I'm not really sure. People may pass an array built from a file or the database so it'd be altered but I don't know if this is that common. What do you think ?
As for the two flatten calls, I agree that they don't fit here. Actually this was here because we can pass arrays to the uncoutable method (e.g. here) but the words parameter is still an array so we ended up in having an array of arrays. Another implementation could be:
@uncountables += words.flatten.map(&:downcase)Which is also a bit faster.
Since d3071db, the apply_inflections method check if the downcased version of a string is contained inside the "whitelist" of uncountable words. However, if the word is composed of capital letters, it won't be matched in the list while it should. We can't simply revert to the previous behavior as there is a performance concern (benchmarked over /usr/share/dict/words): Before d3071db 135.610000 0.290000 135.900000 (137.807081) Since d3071db 22.170000 0.020000 22.190000 ( 22.530005) With the patch 22.060000 0.020000 22.080000 ( 22.125771) Benchmarked with http://git.io/aFnWig This way, the solution is to put the down-case version of words inside the @uncountables array.
Make the apply_inflections method case-sensitive
Hello,
Since d3071db, the apply_inflections method check if the downcased version of a string is contained inside the "whitelist" of uncountable words. However, if the word is composed of capital letters, it won't be
matched in the list while it should.
We can't simply revert to the previous behavior as there is a performance concern (benchmarked over
/usr/share/dict/words):Benchmarked with http://git.io/aFnWig.
Have a nice day.