Re: Mutables Was: [lang] TODO for 2.1

[__matthewHawthorne]

Are we now in agreement about the features for mutable numbers?  If so, 
I can update my submission with what we've discussed, and resubmit the 
enhancement to [primitives] instead of [lang].

The primary changes are:

- Addition of Mutable interface

Mutable
   setValue(Object)
   Object getValue()
- Addition of primitive setter/helper in each class.  For example:

   MutableByte
       setValue(byte)
Which package are we thinking... org.apache.commons.primitives.mutable?

Anything else?



Stephen Colebourne wrote:

----- Original Message -----
From: "__matthewHawthorne" <[EMAIL PROTECTED]>
 

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



 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]