commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Mon, 01 Sep 2003 02:53:21 GMT

On 31 Aug 2003, __matthewHawthorne wrote:

> About a week ago, I submitted an initial implementation of mutable
> numbers, in a bug report:
> Another developer noticed that similar classes were recently added to
> Geronimo.  More details are in the bug report dialog.

Cool. I'm usually guilty of not checking bugzilla enough, so will go read
it :)

> As a start, I suggest that we all take a look at these Geronimo classes,
> as well as the classes that I've written, and see what everyone thinks.

Sounds good.

> My goal was to make the classes as small and simple as possible.  I
> overrode all of the methods from java.lang.Number such as byteValue()
> and intValue(), and also added Object versions of these, such as
> byteObject() and intObject().

Small = good. Don't want to have lots of repitive code to maintain.

> Having looked at the Geronimo implementation, and seeing the code that
> Henri proposed, I think it may be better to create a Mutable interface,
> with the following methods:
> void setValue(Object)
> Object getValue()


> My implementation also contains primitive setters, such as:
> setValue(double)

[What I called Helper methods]

> *) Should helper mutable methods exist?
> What do you mean by this?

setValue(double) etc.

> *) Should static methods from the Boolean class be implemented?
> -1, I don't think so.

I'm thinking the same.

> *) Should the naming convention be MXxxx
> I think MutableXXX is clearer, but either are OK.

Am happy with either.

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

Sounds good. The bad side of using primitives is that in many cases we
should use the method in the Xxxx class implementation. Having a wrapped
Xxxx makes this easier.

> *) Is a .mutable subpackage okay?
> I prefer lang.math

Boolean? Byte? String? None of these belong in lang.math.

> *) 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()
> }
> I'm not sure if this is a good way to do it or not.  I think my tests
> were pretty thorough, and it seemed OK.

I like it. Very simple. However it needs a little type checking.
Currently, applying the same concept to Integer means that we'd have 'int's
that equal 'double's.

However, it also will fall over with a class not found when 'o' is another
Mutable instance, when the superclass is final. Namely String/Boolean.


View raw message