I would not put in the Boolean stuff. They are not numeric and I don't see any reason for them being in a numbers class.
Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 12, 2003 3:43 AM > To: Jakarta Commons Developers List > Cc: [EMAIL PROTECTED] > Subject: Re: [lang] MutableNumbers: if you have an idea, > please share it. > > > > 1) Would MutableNumbers be useful? > They do save an object creation, and can be passed into > another method to be changed. They are useful. > > > 2) Is double an acceptable internal type for all numbers? > It seemed > > simplest to choose the largest type, and upcast all other types. > The assumption that double is sufficient to store all numbers > is flawed. Not all long values can be stored in a double. > > It will be necessary to declare the instance variable in each > subclass, and of the correct type (as per Integer/Float/Double etc). > > > 3) Where should the following methods go? > > > > Byte byteObject() > > Short shortObject() > > Integer intObject() > > Long longObject() > > Float floatObject() > > Double doubleObject() > These should be abstract in MutableNumber and concrete in the > subclasses. > > > 4) Would the following be good additions also? > > > > boolean booleanValue() > > setBooleanValue(boolean) > > Boolean booleanObject() > Maybe. I don't mind them being added. > > Stephen > > From: "_matthewHawthorne" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 28, 2003 10:16 PM > Subject: [lang] MutableNumbers: if you have an idea, please share it. > > > > I have started some initial work on the concept of MutableNumbers, > > that I mentioned a few months ago. Before I begin anything > major, I > > want to get some feedback. > > > > Any comments and suggestions are appreciated, especially > with regard > > to class design, and usefulness. > > > > > > -------------------------------- > > Initial design > > -------------------------------- > > > > MutableNumber > > > > // Internal value > > double value; > > > > // java.lang.Number overrides > > byte byteValue() > > short shortValue() > > int intValue() > > long longValue() > > float floatValue() > > double doubleValue() > > > > // Mutator methods > > setByteValue(byte) > > setShortValue(short) > > setIntValue(int) > > setLongValue(long) > > setFloatValue(float) > > setDoubleValue(double) > > > > > > Two sample extensions would be: > > > > MutableInteger > > MutableInteger(int) > > > > MutableFloat > > MutableFloat(float) > > > > > > -------------------------------- > > Questions > > -------------------------------- > > 1) Would MutableNumbers be useful? > > > > A typical usage could be: > > > > Thing.setId(new Integer(1)) > > Thing.setId(new Integer(2)) > > > > Thing.setId(new MutableInteger(1)) > > Thing.getId().setIntValue(2) > > > > But, in looking at this, it doesn't seem to make much of a > difference. > > Are there any other uses? > > > > > > 2) Is double an acceptable internal type for all numbers? > It seemed > > simplest to choose the largest type, and upcast all other types. > > > > > > 3) Where should the following methods go? > > > > Byte byteObject() > > Short shortObject() > > Integer intObject() > > Long longObject() > > Float floatObject() > > Double doubleObject() > > > > The could all easily be placed in the MutableNumber class > itself, but > > this would almost eliminate the need for subclasses entirely. > > > > If MutableNumber is not abstract, it becomes: > > > > MutableNumber num = new MutableNumber() > > num.setIntValue(5) > > num.intObject() > > > > vs. > > > > MutableInteger mutInt = new MutableInteger(5) > > mutInt.intObject() > > > > > > 4) Would the following be good additions also? > > > > boolean booleanValue() > > setBooleanValue(boolean) > > Boolean booleanObject() > > > > This may duplicate some current commons functionality (in > BooleanUtils > > I believe), but I think this addition would be consistent with the > > other methods. > > > > > > > --------------------------------------------------------------------- > > 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]
