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.
Hen
On Thu, 10 Jun 2004, matthew.hawthorne wrote:
> I just made a checkin of some initial code for mutables. I haven't used
> CVS in
> a few months now (switched to subversion) so let's hope I didn't screw
> anything up.
>
> I have to admit that I haven't looked at this code for a good time,
> since around
> August maybe. So all are welcome to take a look and make improvements.
> I don't really have a solid use case for these classes anymore, so I'd
> imagine
> that others will have a better insight in that regard.
>
> The test coverage is pretty good, I think in the 70% range. I remember
> learning
> some weird things about the way Java handles primitive number
> conversions, as
> I was trying to get the tests to pass. If something looks bizarre give
> a yell and
> I'll investigate.
>
> ---------------------------------------------------------------------
> 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]
