commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [math] formatting composite objects
Date Sun, 27 Jul 2008 19:16:41 GMT
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


Mime
View raw message