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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
