On 31 Aug 2003, __matthewHawthorne wrote:
> About a week ago, I submitted an initial implementation of mutable
> numbers, in a bug report:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22717
>
> 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()
+1
> 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.
Hen
|