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 [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > 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" <[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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
