Extend toString(value,format) to work with numbers

[tfmorris]

Currently the format string is only used when formatting dates, but it would be desirable to have it work with numbers as well. This would allow for things like radix conversion, integer formatting of large numbers, etc. Dates would continue to get formatted using SimpleDateFormat, but numbers would get passed to java.util.Formatter.

[tfmorris]

This snippet will work, but after playing with it, I think it's too confusing for the user to deal with our multiple internal number representations, especially since we transparently coerce them as necessary everywhere else. We'll need a better solution.

        if (args.length == 2 && args[1] instanceof String) {
            Object o2 = args[1];
            if (o1 instanceof Calendar || o1 instanceof Date) {
                DateFormat formatter = new SimpleDateFormat((String) o2);
                return formatter.format(o1 instanceof Date ? ((Date) o1) : ((Calendar) o1).getTime());
            } else if (o1 instanceof Number) {
                return String.format((String) o2, (Number) o1);
            }

[thadguidry]

The best code I have seen for dealing with number formatting is in Pentaho and its usage of java.text.NumberFormat to handle this with Format Masking and NumberFormat can use different Locale's

NumberFormat nf = NumberFormat.getInstance(Locale.FRENCH);

https://github.com/pentaho/pentaho-kettle/blob/master/core/src/main/java/org/pentaho/di/core/row/value/ValueMetaBase.java#L81

https://github.com/pentaho/pentaho-kettle/blob/master/core/src/main/java/org/pentaho/di/core/row/value/ValueMetaBase.java#L957

https://github.com/pentaho/pentaho-kettle/blob/master/core/src/main/java/org/pentaho/di/core/row/value/ValueMetaBase.java#L1339

https://github.com/pentaho/pentaho-kettle/blob/master/core/src/main/java/org/pentaho/di/core/row/value/ValueMetaBase.java#L3815

[thadguidry]

Yet another possible way would be to use java.text.MessageFormat ?

[wetneb]

This is a legitimate enhancement request so removing the "to be reviewed" tag.

[tfmorris]

So, it looks like perhaps this didn't get documented because it wasn't a great solution. I guess the question now is whether we need to maintain backward compatibility for the (undocumented) format strings. We should also think about how we extend this to non-default locales.

The one-parameter version uses Double.toString()/Long.toString() while the two parameter version uses String.format(pattern string, number).

Perhaps we should switch to a different function (format()) for compatibility and use Number.getInstance().format() for the single argument version and DecimalFormat(pattern) for the two argument form (and specify how non-default locales work).