commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Mon, 01 Sep 2003 21:17:36 GMT
----- Original Message -----
From: "__matthewHawthorne" <mhawthorne@alumni.pitt.edu>
> > *) Is a .mutable subpackage okay?
> > > I prefer lang.math
> >
> > Boolean? Byte? String? None of these belong in lang.math.
I suggest we get the Mutable Numebr classes in and working first, then think
about Boolean/String.

> > *) 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.

> 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

> > *) 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.


Finally, we might want to consider the role of [primitives] here. Perhaps
these classes belong there?

Stephen




Mime
View raw message