commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] formatting composite objects
Date Tue, 29 Jul 2008 18:49:36 GMT
Brent Worden a écrit :
> The getInstance() method can not return a sole instance because the
> default locale can change via java.util.Locale#setDefault
> The purpose of the format setters is to provide similar behavior as
> found on java.text.NumberFormat with the ability to modify formatting
> parameters.  They provide a convenience to having several methods to
> alter the parameters for each of the number parts.
> I would not be in favor of making the type immutable because it is
> contrary to the design of the standard Format types.

This explanation is fine for me. I will not implement the changes I

By the way, the changes I implemented a few days ago were not related to
this: they were simply for the sake of extracting the CompositeFormat


> On Sun, Jul 27, 2008 at 2:16 PM, Phil Steitz <> wrote:
>> Luc Maisonobe wrote:
>>> Hello,
>>> I am writing a new Vector3DFormat class in the spirit of the
>>> ComplexFormat class for input/output.
>>> Since some parts are common (parsing one component, handling locales), I
>>> have extracted a CompositeFormat base class from ComplexFormat and will
>>> use it as the base class for Vector3D and perhaps for future other
>>> classes.
>>> I see that the current ComplexFormat class provides two getInstance()
>>> static methods whose javadoc is: "Returns the default complex format for
>>> the current locale". The instance returned is *not* a singleton, it is
>>> rebuilt each time but the javadoc doesn't says it. Since the class is
>>> not immutable (there are set methods), it may lead to surprising results
>>> to users.
>>> I see two options here:
>>>  1) We keep a mutable class, and either we replace the two getInstance()
>>>    static methods by constructors or we rename them createInstance()
>>>  2) We change the class to immutable and we remove the set methods
>>> My preference is 2). I don't like mutable objects, especially for a low
>>> level library which can be reused differently from various other middle
>>> level libraries and directly by users. Each part of the code should know
>>> exactly what the instances it uses do, and either use the default one
>>> provided by getInstance for general purpose, being sure nobody with
>>> change its settings under the hood or use a specific instance with
>>> custom settings.
>>> What do you think about it ?
>> I agree with you on the name change s/get/create or "new" but I think users
>> of ComplexFormat need to be able to pass in formats, so the factory itself
>> either needs to be mutable or have these things in constructors.  In theory,
>> someone might want to use the setters; though I can't think of a real world
>> use case.  The problem with the name change is backward compatibility.  I
>> would be +1 for deprecation and introducing "create" or "new" methods.
>> Base CompositeFormat class looks good.
>> Phil
>>> Luc
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message