Cool. Practically done it, but getting a unit test failure for the testPrimitiveAccessors. Will figure out and submit.
The constructor for MutableNumber is odd. It's a) Empty, so possible to have a MutableNumber without a value yet. b) package-scoped, so only we can extend it. I'm not sure if there are good uses for a), but b) seems like something we don't need to do. Hen On Sat, 12 Jun 2004, matthew.hawthorne wrote: > Henri Yandell wrote: > > First thought when looking at the code is that we could simplify things > > with a protected Number in MutableNumber, and move the intValue etc > > methods up into MutableNumber. > > > > The getValue/ setValue(Object) can go up too, and all that would be left > > in the mutable subclass is the primitive override and the constructor. > > > > Pro: Less code in the subclasses. > > Con: A protected rather than private variable. More memory is taken up > > with the mutable part being an Object and not a primitive. > > > > Just a thought. > > > I think the pro of simpler code may be bigger than the con of memory loss. > Those involved in hardcore performance tweaking may disagree. For me, > the mutable classes were more about the added functionality than the savings > in memory, so I'm in agreement with you here. > > --------------------------------------------------------------------- > 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]
