commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent Worden" <>
Subject Re: [math] formatting composite objects
Date Mon, 28 Jul 2008 23:01:29 GMT
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.

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:

View raw message