+0.8 ;-)
you might want to list the full API for MutableInteger just to be
sure...mine below:
On Mutable (interface):
setValue(Object)
getValue()
On MutableNumber (interface):
getNumber()
setNumber(Number)
shortNumber() - maybe only on implementation?
getShortValue() - synonm for JavaBean tools
setShortValue(short)
etc. for int, long, float, double
I suggest you may want two implementations eventually for overflow
(short) Integer.MAX_VALUE:
1) works with a silly result
2) throws ArithmeticException (or a new OverflowException)
Stephen
----- Original Message -----
From: "__matthewHawthorne" <[EMAIL PROTECTED]>
> 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]
