commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Wed, 03 Sep 2003 05:16:27 GMT
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" <mhawthorne@alumni.pitt.edu>
> > 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