commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [lang] mutables
Date Mon, 21 Jun 2004 12:38:46 GMT

Jar size isn't important, maintainable code size is why I suggested moving
to storing the value in the abstract.

Am happy to rollback if that is desired.

Hen

On Mon, 21 Jun 2004, Stephen Colebourne wrote:

> I've only now got a chance to review this (holiday ;-).
>
> I am less than happy with the current CVS code as it involves storing each
> subclass as an Object. IMO, the whole point of this package is to create
> classes that hold each value as a primitive, as per the java lang Number
> subclasses, and [lang] Range classes.
>
> I know that this creates more code in the jar, but that is irrelevant next
> to the new Integer() or new Byte() etc in the constructor of the CVS code.
> Creating these additional objects is a memory hog and bad for the gc. I can
> see no advantage other than jar size for the CVS code, hence would -1 the
> current CVS.
>
> I haven't checked if this was how the classes were originally. If so, can we
> rollback?
>
> Stephen
>
> ----- Original Message -----
> From: "Henri Yandell" <bayard@generationjava.com>
> > 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: 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
>
>
> ---------------------------------------------------------------------
> 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