commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Tue, 02 Sep 2003 13:49:06 GMT

> Another question, should MutableDouble provide all of DoubleUtils [okay,
> NumberUtils, I'm trying to think in patterns] as instance methods?

I don't think so.  NumberUtils methods which operate on a Number should
be able to use a MutableNumber in the same way.

As far as whether to put these classes in [lang] or [primitives], it all
depends on how we define the purpose of the classes.  Are they simple
language extensions, or are they a bridge between the primitive and
Object worlds?  They both make sense to me, so if you're leaning towards
[primitives], let's put them there.




On Tue, 2003-09-02 at 06:29, Henri Yandell wrote:
> On Mon, 1 Sep 2003, Stephen Colebourne wrote:
> 
> > > > *) Should the MXxxx decorate an Xxxx or an xxxx. [ie primitive or
> > > > > wrapper?]
> > > > > I prefer primitive, it would prevent having to create a new Object
> > each
> > > > > time the value changes, which is a part of the reason that these
> > classes
> > > > > are a good idea.
> > Should be primitives, as object creation needs to be avoided.
> 
> I think it depends on how we do the methods. If we delegate to another
> class, Double or DoubleUtils, then it ought to be the wrapper as there
> will be too much object creation. If we implement it all ourselves, then
> it should be primitive.
> 
> > > It depends on how the methods are implemented.  The way I did it allowed
> > > me to implement the majority of the java.lang.Number methods in the
> > > abstract MutableNumber class, so each specific type didn't have a lot to
> > > do.
> > This caused problems in the old (deprecated) implementation of NumberRange.
> > Although annoying to code, special primitive specific subclasses are better
> 
> Much harder for us to keep in sync with Sun though. I guess the Unit Test
> could be created to test sync-ness in a nice general way.
> 
> Another question, should MutableDouble provide all of DoubleUtils [okay,
> NumberUtils, I'm trying to think in patterns] as instance methods?
> 
> > > > *) How exactly should equals() work [I'm ignoring it for the moment]
> > > > > I made it expect a Number:
> > > > >
> > > > > boolean equals(Object o) {
> > > > > return doubleValue() == ((Number)o).doubleValue()
> > > > > }
> > Danger with this is that the equals() isn't reflective. Comparing a
> > MutableInteger to a Integer would suceed or fail based on which was on the
> > left hand side.
> 
> Yeah. I expect equals() to be the main pain in the arse.
> 
> > Finally, we might want to consider the role of [primitives] here. Perhaps
> > these classes belong there?
> 
> I'm +1 for them going into primitives.
> 
> Hen
> 

Mime
View raw message