I'm ambivalent on the primitives vs lang and think it'll depend on the size of the primitives code and how the code feels.
I'm happy to have it kicking in sandbox to start with, though it makes the audit trail a bit harder. Mainly I just want to see the code and start complaining :) One issue with having [primitives]. My interest is [perversely as usual] on MutableBoolean because I think it should be simple and MutableString, because it's an outspoke of StringUtils. I'd want MutableString to automatically contain any StringUtils method which is relevant, which suggests a dependency on Lang. Of course, Strings are not primitives, so a MutableString might live in Lang instead of primitives. Which means that the 'Mutable' interface will need to live either in [mutable] or that [lang] or [primitive] would be considered the ancestor project. Given this, I think my special case scenarios just completely argued for this code being in [lang] :) Hen On Wed, 3 Sep 2003, Stephen Colebourne wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
