On Fri, 11 Oct 2002, Steve Downey wrote:
> > 2) Mutable primitive classes. Pondered this at the hospital today. Do we
> > want such things? new MutableInteger(); mi.setValue(42); etc. Same for
> > MutableString.
> >
> I'm not so sure about Mutable value classes. I'd want to see a use case for
> them first. IOW, what does it gain over this.value = new Integer(42)?
> If there's shared mutable state, I think it's usually within the same class. I
> don't see the utility of a mutable Integer that's shared between unrelated
> classes. And within the same class, I'd think just using members is more
> natural.
Yeah, my reaction was to think no. But then I decided that discussion on
it would be very interesting :)
> > 3) Constant. I'm still unsure if this is good or not :) It's been in and
> > out and in etc. My reasons for deciding it was shit was cuz I wanted to
> > use == when I initially grew to love it and RMI/Java means I have to use
> > .equals. But Enum makes that same choice. So is a simple-enum concept
> > needed.
> >
> I think Enum lets you use == as well as equals(). At least, it works for
> serialization. Am I missing something?
ClassLoaders I think.
> > 5) StopWatch. Currently this is in [util], but as its basically a wrapper
> > for System.currentLongTimeBlah I thought I'd mention it.
> >
> Considering how often I write stopwatches inline, I think it sounds useful.
> It's not that it's hard, it's that it's repetetetetive.
Yep. It was in GenJavaCore and I never used it. Then I found out the guy
who sits opposite me was using it constantly...
Hen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
