3) use explicit format names: numberFormat, timeFormat, dateFormat and
timestampFormat, instead of a generic 'format' parameter defaulting to
an ubiquitous 'default' value. I'd also like to have the default formats
be the international formats used by HTML5 (RFC 3339).
+1000
:-)
The new form
Claude,
On 11/17/16 12:58 PM, Claude Brisson wrote:
> There are several things I'd like to do for the tools before releasing
> them:
>
> 1) deprecate the ConversionTool:
> - date formatting and parsing methods are redundant with (and less
> complete than) DateTool ones.
> - number formatt
+1 deprecate and refactor away. this all sounds good.
On Thu, Nov 17, 2016 at 10:32 AM, Sergiu Dumitriu wrote:
> On 11/17/2016 12:58 PM, Claude Brisson wrote:
> > There are several things I'd like to do for the tools before releasing
> > them:
> >
> > 1) deprecate the ConversionTool:
> > - d
On 11/17/2016 12:58 PM, Claude Brisson wrote:
> There are several things I'd like to do for the tools before releasing
> them:
>
> 1) deprecate the ConversionTool:
> - date formatting and parsing methods are redundant with (and less
> complete than) DateTool ones.
> - number formatting and
On 17/11/2016 19:10, Mike Kienenberger wrote:
On Thu, Nov 17, 2016 at 12:58 PM, Claude Brisson wrote:
There are several things I'd like to do for the tools before releasing them:
1) deprecate the ConversionTool:
- the only remaining feature is a toStrings() method (which does
splitting a
On Thu, Nov 17, 2016 at 12:58 PM, Claude Brisson wrote:
> There are several things I'd like to do for the tools before releasing them:
>
> 1) deprecate the ConversionTool:
> - the only remaining feature is a toStrings() method (which does
> splitting and optional trimming). A single method doe
There are several things I'd like to do for the tools before releasing them:
1) deprecate the ConversionTool:
- date formatting and parsing methods are redundant with (and less
complete than) DateTool ones.
- number formatting and parsing methods are redundant with the
NumberTool and Ma