Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for comma as decimal separator #304

Open
dush opened this issue Mar 14, 2019 · 3 comments
Open

Support for comma as decimal separator #304

dush opened this issue Mar 14, 2019 · 3 comments

Comments

@dush
Copy link

dush commented Mar 14, 2019

Types::Params::Float and Types::Params::Decimal should coerce number parameters with comma as decimal separatotor (eg "12,34")
ISO8601 allows using comma "," or full stop "." as decimal separator. Of these, the comma is the
preferred sign

@solnic
Copy link
Member

solnic commented Mar 18, 2019

We could add support for this as either a separate type or based on additional configuration. We need to use regexps to check the format and that is very slow, that's why this should be an opt-in behavior.

@dush
Copy link
Author

dush commented Mar 18, 2019

I know that I can define my own type that does it, but as I understand Params category of dry-types is intended for HTTP params processing which is often user input. I think it could be supported by default as roughly half of the world will write decimal/float numbers wit comma as separator and it is even in ISO standard.
If you need performance than you can just use Types::Coercible::Decimal or Float.
May be you don't even need regexp, you might just try Float(input.tr(',', '.')) if input is a String.

@solnic
Copy link
Member

solnic commented Mar 19, 2019

It's not that simple 😄 Check out this table to get an idea: https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html

One of the reasons why dry-types was created was to remove generic coercions. We want coercions to be as narrow as possible in order to avoid situations where something is coerced by a mistake or incorrectly. I think people should be 100% clear regarding the number format they want to support and we should have types that make supporting various formats as simple as possible. For instance I would define validation rules for formats that my system is supposed to support and have corresponding coercion types (if needed). This way you remove any ambiguity from your coercion/validation layer.

We can really make this quite simple for the users. ie we could add predefined coercion types that we could access by country identifiers or some other identifiers that could be understood by people. What we should not do is blindly assuming that the comma is used in one way or the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants