Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <488F6640.5070501@free.fr>
Date: Tue, 29 Jul 2008 20:49:36 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] formatting composite objects
References: <488AE9D3.40103@free.fr> <488CC999.8050707@gmail.com>
 <bb73f6570807281601m5633cfe9je0ab65c8516abace@mail.gmail.com>
In-Reply-To: <bb73f6570807281601m5633cfe9je0ab65c8516abace@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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
suggested.

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
superclass.

Thanks
Luc

> 
> On Sun, Jul 27, 2008 at 2:16 PM, Phil Steitz <phil@steitz.com> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org