I don't see why given
you one should pick 12678. I don't see why you don't pick 1000 out of
Wouldn't that be useful? What would a user could possibly mean other
than 1000? One could ask.
These are good points.
I'm not sure what kind of app and UI would cause someone to mistakedly
in a single field and expect to have "12" stored (and lose "678"?),
but I suppose it could happen. That does seem far, far more edge case
than input like "1 234" though.
I don't think it would make nearly as much sense to strip e.g. "$" or
"%". If someone puts units in a numerical field, chances are the field
is intended for some other unit.
So while I think I get the point about arbitrariness, I still think
stripping whitespace uniquely stands out as being helpful without real
downsides (if you grant that the "12 678" example is unlikely).
Other characters may be ambiguous (spaces and commas), typos
(letters), intended as units etc and make more sense as validation
errors. But spaces are often used intentionally and are not treated
intuitively by Rails.
While there is something of a slippery slope here, I don't see
practical downsides to removing spaces, in terms of breaking existing
UIs or code.
If the only real problem is that it's arbitrary, and consistency with
to_i/to_f makes things easier for the programmer, note that this is
already not the case:
if value == false
elsif value == true
elsif value.is_a?(String) && value.blank?
That's what Rails does currently. Unlike to_i, it will turn a blank
string to nil, not zero, and turn bools into numbers. These changes
make some sense for an ORM. Making one further change to better handle
the general domain of non-programmer input makes sense to me.
For instance, in my big day job app, I use this simple attribute
stripper for string based columns.
On a side note: I do something similar. You can lose the ".dup" since
".strip" will create a new String object, not modify "self" in place.