commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Wed, 03 Sep 2003 04:19:53 GMT

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" <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
> >
>
>
> ---------------------------------------------------------------------
> 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