Make model.number = "1 234" store 1234 instead of 1?

Since our users have been complaining about putting "1 234" in a form
and having 1 stored instead of 1234 (because of how to_i/to_f works),
I made a simple monkeypatch to get their expected behavior:

https://gist.github.com/3d99d172175ee3bc64a1

I'd be happy to submit a patch to Rails, but I wanted to check here
first. Is there good reason not to make this behavior default?

I think if you are validating numercality it should be an error.
Removing spaces seems like unexpected behavior to me.

Since our users have been complaining about putting “1 234” in a form

and having 1 stored instead of 1234 (because of how to_i/to_f works),

I made a simple monkeypatch to get their expected behavior:

This is not something that should go in core, IMO.

If on your specific application it makes sense to do that, then use a before_validation callback to strip the spaces off the value on the fields for which this makes sense.

Cheers

Don't see this in core.

Looks like a custom numerification that makes sense in your
application. Both that one and Rails' make arbitrary assumptions about
what they tolerate, but Rails is coherent with Ruby and I think the
current behaviour is better because of that.

Custom rules, yours or others, can be programmed as needed.

Couldn't agree more. This isn't by any means a "feature" for Rails-Core. Maybe
you should look at the attribute_normalizer plugin.

Cheers,

Amol Hatwar (rubygem)

Thanks for the feedback, all.

Can anyone think of a specific example of when the behavior I proposed
would be undesirable? I can't think of anything.

For most users, I imagine the suggested behavior follows the principle
of least surprise and the current behavior does not. End users likely
care less about consistency with to_i/to_f and more about the web app
doing what they mean.

I think if you are validating numercality it should be an error.

Why would you want to show the user a validation error instead of just
doing what they would expect, though?

Removing spaces seems like unexpected behavior to me.

Definitely if it was a string field, but for an integer or decimal
column? Per above: when would the user *expect* the number to be cut
off at the first space?

I understand it is not arbitrary in the sense that it is based on the
feedback of some users of *your* application. I didn't mean it is a
blind customization, but that is as arbitrary a priori as removing any
spurious character.

I have applications where numeric input filters remove any \D that is
not a comma or a period becaue that make sense for them, so I
understand your motivation. Removing \D is as arbitrary as removing \s
in my view, and thus I prefer the programmer to do that, instead of
core to do that by default.

Is it, though?

I can think of no case when a space can't be just dropped from numeric
input without losing anything.

Letters and special characters on the other hand should probably be
caught by validations in most apps, since we can't know if they hit
"q" but meant to hit 1, or if their comma was intended as a decimal
comma and not a thousand separator, etc.

These are reasons not to remove those characters. I can think of no
reasons not to remove spaces. So that's not very arbitrary :slight_smile:

I would like to see specific examples of why it might be a bad idea to
remove the spaces. I'm hearing nays but I don't get what issues you
see with this. I do see the benefits, though: more intuitive and human-
friendly input handling.

Hey, this is not a back and white issue. You propose a patch in -core,
and you get feedback. My feedback is that I do not see it in core.

In my view being tolerant to spaces can make sense for some, but that means that

   12 678

is goona be 12678 by default in Rails. I don't buy that's good.

I don't think that interpretation is any better than 12 a priori. So
albeit I understand your motivation, as I said, I think the current
default is just as valid as yours, and in addition coherent with what
a Ruby programmer would expect from a string to number conversion.

What we'd lose is consistency in our framework.

It would be an error to try to provide you with use-cases for why this is a bad idea. To do so would miss a very important part of what makes Rails (and ruby for that matter) great. The main reason it's a bad idea is that it introduces an inconsistency into an otherwise consistent framework and language.

One of the huge wins that Ruby has over other languages, and something which Rails remains (mostly) true to, is that it's logically consistent. One can learn the principles of ruby and proceed to make accurate deductions on language structure and behavior based on those principles. Rails is (mostly) the same (and is getting more consistent as it matures).

I go further than Xavier who said that "12 678".to_i => 12 is "just as valid as" => 12678. A space is not a number, no one can argue that it is. Also, one could never deduce the behavior you're suggesting Henrik. One would have to accept that "removing spaces from numbers is just the way it is". Why a space and not a tab? Why a space and not a comma? "It just is."

If you want a tool that covers this type of special use-case in the core, then I'd suggest you try PHP - it's one of the things it does really well. It encodes common use cases without any regard to consistency.

Jason

> I would like to see specific examples of why it might be a bad idea to
> remove the spaces. I'm hearing nays but I don't get what issues you
> see with this. I do see the benefits, though: more intuitive and human-
> friendly input handling.

Hey, this is not a back and white issue. You propose a patch in -core,
and you get feedback. My feedback is that I do not see it in core.

Very glad for the feedback. Was just trying to get to specifics beyond
just "I do not see it".

So I'm getting that you (and others that commented) prefer consistency
(with to_i/to_f) for the Ruby programmer. Fair enough. I disagree, but
it's an easy override per-app, so no big deal.

I go further than Xavier who said that "12 678".to_i => 12 is "just
as valid as" => 12678. A space is not a number, no one can argue that
it is.

That is how computers think, but not non-programmer end users. But I
see your point about consistency. Perhaps it would be better to use
some sort of form/submission object that handles spaces (and periods
and commas if you want to get into that mess) as the user would
expect, and leave the attribute writers as is.

Also, one could never deduce the behavior you're suggesting

Henrik. One would have to accept that "removing spaces from numbers
is just the way it is". Why a space and not a tab? Why a space and
not a comma? "It just is."

The point about consistency is valid, but this isn't quite. Whitespace
can be unambiguously removed; commas (and periods) in numbers are
ambiguous. That's why.

If you want a tool that covers this type of special use-case in the
core, then I'd suggest you try PHP - it's one of the things it does
really well. It encodes common use cases without any regard to
consistency.

No need to get nasty :wink: I proposed something that would improve the
experience for end users without any practical negative effects that I
can tell. It seems we simply disagree about whether user experience
trumps consistency.

In general I have found the core teams advice to be very very helpful
and listening to their (positive and negative) feedback has helped me
write patches and contribute. Their technical and gut reactions come
from a wealth of experience. It reminds of a book I was reading by the
pragmatic programmers on agile learning and skill development. For
such a small thing, some on the core team might not be able to fully
express their "intuition" and expertise on their feedback. Despite
their articulation, it is good advice.

My opinion on the matter is aligned with those that have already
spoken. Sure I might put something like your code into my own app, I
can totally see it. But it's too far and assuming to much for core
code. For instance, in my big day job app, I use this simple attribute
stripper for string based columns.

http://gist.github.com/219579

A good idea... hell yea. My users are probably the worst low tech
users that type in all uppercase, using IE5 that you can find. Does
this belong in core... my gut says no... although there are probably
tons of smarter reasons that I can not express.

  - Ken Collins

I think we rather disagree on whether that gives a significant better
user experience.

For you it is clear it does, for me (and I guess a few others) the
patch just relaxes number input in one of a miriad ways. In particular
I don't see why given

    12 678

you one should pick 12678. I don't see why you don't pick 1000 out of

    $1000

Wouldn't that be useful? What would a user could possibly mean other
than 1000? One could ask.

Given that I think the weakness in the patch is as arbitrary as any
other numerification that accepts strings that do not contain
well-formed numbers. That is, everything being equal (again, in my
opinion), I chose the behaviour that is consistent with Ruby. Because
everything being equal we get *in addition* expected behaviour from
for the programmer. And in any case it is configurable if an
application has custom rules.

I understand you disagree, that's OK :).

What I really think is that the current behaviour would also be unacceptable... I would prefer an exception to be generated when converting "12 34" to integer, instead of a result of 12 that would be inconsistent with the user input...

Maybe ActiveRecord should generate automatically a validates_numericality_of for each numeric field and include options for :only_integer for integer fields. When a user explicitly set the validation, it should override the automatic one...

That would be much more consistent in my opinion, regarding user's input...

Rodrigo.

What I really think is that the current behaviour would also be
unacceptable... I would prefer an exception to be generated when
converting "12 34" to integer, instead of a result of 12 that would be
inconsistent with the user input...

Agreed. It's also supposed to be validating numericality, so if there
is a character in there which is not a number (a space) it should not
validate successfully.

All the posts to this point have suggested that a space is not part of
a numeric, so it would seem to make sense to back that claim up by
making it not validate.

TX

In particular
I don't see why given

12                             678

you one should pick 12678. I don't see why you don't pick 1000 out of

$1000

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
input
    12 678
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:

      def convert_number_column_value(value)
        if value == false
          0
        elsif value == true
          1
        elsif value.is_a?(String) && value.blank?
          nil
        else
          value
        end
      end

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.

http://gist.github.com/219579

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.

Henrik,
I don't think Rails' principal of least surprise was meant necessarily
to extend to your end-users' experience. It applies to YOUR
experience. Then, in turn, you are responsible for making your users'
experience unsurprising (amongst many other positive adjectives).

The first development framework that is able to make the *end-user's*
experience unsurprising will be a smashing success -and is still
decades away.

As a developer, I would be surprised by having "1 234" turn into 1234
because I know that is not how Ruby works.

-Chris