commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <st...@mungoknotwise.com>
Subject RE: Mutables Was: [lang] TODO for 2.1
Date Tue, 02 Sep 2003 23:02:07 GMT
I'm still not comfortable with primitive. You might have missed my last
posting, but in it I express the opinion that a group of wrapper classes
that enhance functionality of wrappers that live in java.lang, would more
naturally fit in o.a.c.lang.

Otherwise +1 to the rest of the summary.

Steven Caswell
steve@mungoknotwise.com
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."


> -----Original Message-----
> From: __matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu] 
> Sent: Tuesday, September 02, 2003 4:36 PM
> To: Jakarta Commons Developers List
> Subject: Re: Mutables Was: [lang] TODO for 2.1
> 
> 
> 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
> >
> >
> >
> >
> >  
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 



Mime
View raw message