Closed (fixed)
Project:
Format Number API
Version:
6.x-1.0
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Nov 2008 at 22:13 UTC
Updated:
13 Nov 2008 at 13:39 UTC
Jump to comment: Most recent file
Comments
Comment #1
markus_petrux commentedAgreed.
Suggestions for the function name?
unformat_number($string)?Comment #2
ztyx commentedWhat about
parse_number($string),deformat_number($string)orparse_formatted_number($string)?Also, I suggest this function do:
FALSEif all else fails.Comments?
Comment #3
markus_petrux commentedI like
parse_formatted_number($string):)BTW, I have to commit a few changes in the module that will turn the site/user settings form into something based on Unicode Locale Data Markup Language (LDML). The textfields for thousands separator and decimal point can be turned into radios with a known set of symbols.
If we look at the table of possible symbols for decimal point and thousands separator, we have a limited set of combinations (ref. Charts by type: Number symbols). So maybe we could proceed as follows:
Thoughts?
Comment #4
markus_petrux commentedOops! One question remains... what should be returned when input is an empty string?
Options:
1) Return FALSE. But it could be confused with invalid input.
2) Return empty string ''.
3) Add a second argument to parse_formatted_number() that can tell us if number is strictly required. So if 'strict' and input is empty string, return FALSE. If not 'strict' and input is empty string return 0.
4) ... ¿?
I would vote for option 3 :)
Comment #5
markus_petrux commentedI have commited function
parse_formatted_number()that should be available now from CVS, or from the next nightly snapshot.The code looks like this:
Please, check it out and let me know if that covers what you had in mind. :)
Comment #6
ztyx commentedI like your code. I've attached a patch against current CVS changing a pair of things:
static. You only checked one of the three static variables.I'm also attaching a sketch for tests. Have a look at them and see if you find them reasonable. I do. Currently 6 tests out of 51 fails.
Comment #7
markus_petrux commentedIf you would have to use format_number() passing explicit thsep/decpt options, you could simply use PHP's number_format(), so I wouldn't add the option to format_number().
Also, I wouldn't patch parse_formatted_number() just for testing purposes. If that's really needed, the test environment should be able to reproduce the variable conditions that a function may find. Maybe it can be created more than one SimpleTest file, each one able to predefine site/user settings.
SimpleTest is a great tool for QA, but we could better use a separate issue for that. AFAICT, the "Reverse number format" issue is fixed. :)
Comment #8
markus_petrux commentedThat's not really needed either, since settings form (both, site wide and user profile forms) implement the options with radios (impossible to select anything that is not predefined) and also provide a validation routine to ensure the same character is not selected for both symbols.
Comment #9
ztyx commentedWell, I see SimpleTest as a great way of writing a specification too. And since six of the tests failed (all in the testing of
parse_formatted_number()), the specification did not hold.Anyway, I'll create a new issue for this after refactoring the code a bit further.
Comment #10
markus_petrux commented