Re: Quick note about future number handling

> If you wanted to maintain backward compatibility, perhaps you could 
> leave the default as is and provide a method on the 
> Template/Configuration instance for overriding the default formatting.  
> Could also do same with a new computer readable default, allowing 
> existing users to override the default back to the old human readable 
> default (which I've also found to be a total PITA :) ).
> 
> In fact.... would this be nice to have for all types... including Dates 
> etc e.g.
> 
>    configuration.setDefaultFormatting(Number.class, "c");
>    configuration.setDefaultFormatting(Date.class, "string('yyyy-MM-dd')");
>    // etc...
> 
> 
> Actually ... just looked at the API and it appears to already be there 
> on the Configuration class i.e. setNumberFormat(String) and 
> setDateFormat(String) :)  Why did I never see that before :)

The main issue will be when templates are from a 3rd party. JCatapult allows you to ship the templates insides JAR files and then it can dynamically look them up. This makes packaging reusable features easy. However, those templates might break if the configuration is changed.

I vote for changing the default or providing a template level default change. My issue with template level changes is that it is more overhead and boilerplate for every template. I'd rather just see the default changed in 3.0. 

Perhaps someone should collect a list of the backwards incompatible changes and start planning for that release? These would be the items on my list:

	- Type formatting
	- Map handling
	- Direct wrappers as default (this was a pretty long thread a few months ago)

I think I've brought up a couple others, just can't remember them right now.

-bp


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev