commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Tue, 02 Sep 2003 21:36:21 GMT
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" <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