commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <st...@mungoknotwise.com>
Subject RE: Mutables Was: [lang] TODO for 2.1
Date Tue, 02 Sep 2003 21:10:27 GMT
Inline below


Steven Caswell
steve@mungoknotwise.com
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."


> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com] 
> Sent: Tuesday, September 02, 2003 8:29 AM
> To: Jakarta Commons Developers List
> Cc: mhawthorne@alumni.pitt.edu
> Subject: Re: Mutables Was: [lang] TODO for 2.1
> 
> 
> 
> 
> 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.

The equals() method for the JDK wrappers insist on the class being the same.
So, for example, given:

    Short s = new Short(45)
    Long l = new Long(45)
    Double d = new Double(45.0)

Then
    s.equals(l) returns false
    l.equals(d) returns false
    d.equals(s) returns false

Etc.

So if these are intended to be mutable extensions of the java.lang wrappers,
we might want to stick to that convention.

> 
> > Finally, we might want to consider the role of [primitives] here. 
> > Perhaps these classes belong there?
> 
> I'm +1 for them going into primitives.

Except that if these are intended to be mutable extensions of the JDK
wrappers, which are in java.lang, would [lang] be more appropriate? I'd be
more inclined to look for wrapper-based functionality that enhances
java.lang wrappers in [lang] than in [primitives].

And I'm +1 on MutableXxx rather than MXxx. More descriptive.

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



Mime
View raw message