commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Tue, 02 Sep 2003 23:24:32 GMT
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" <steve@mungoknotwise.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
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
> 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
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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