How about coding it in [primitives] and then seeing if it is applicable for [lang]. Uses the sandbox for sandbox type investigation...
A case can be argued either way. IMHO, I prefer keeping all new primitives stuff together and focussing [lang] more on Objects. Stephen ----- Original Message ----- From: "Steven Caswell" <[EMAIL PROTECTED]> To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> Sent: Wednesday, September 03, 2003 12:02 AM Subject: RE: Mutables Was: [lang] TODO for 2.1 > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
