Here's an example of the current state:
MutableInteger
// from Mutable
void setValue(Object)
Object getValue()
// from MutableNumber
Number getNumber()
void setNumber(Number)
// Subclass specific
setValue(int)
I was assuming that we wouldn't need a [int getIntValue()] method, since
it inherits [int intValue()] from java.lang.Number. But do we need this
method, in order to be JavaBean compliant?
Also, instead of [Integer intNumber()], I was thinking
[Object getValue()] could be used, and casted to the corresponding type.
Do you think that the explicit object accessor is necessary?
I don't understand your suggestion about overflows, can you elaborate?
On Tue, 2003-09-02 at 15:51, Stephen Colebourne wrote:
> +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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
