On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Martin D Kealey wrote:
> > Rather, let's have immutable time "values", and methods which return other
> > "values" where various computations (*1) have been applied. Provide
> > constructors which take the Y/M/D/h/m/s/dst_now/dst_rule tuple.
> I followed the bits about the computations, and I think I see what
> you're saying about the constructor, but I don't know what you mean by
> 'immutable time "values"'.  Could you expand on this a bit?

We want an "Instant" class whose objects have value semantics rather than
container semantics. Because:

1. It makes them usable in "pure" code

2. "Date isa Instant" works sensibly: anywhere that expects an Instant, you
can give it a Date. (Assuming we all agree that dates start at midnight, but
then we *are* talking specifically Gregorian dates.)

(If you have container objects, that can't work, and neither can the
reverse, tempting though it is. So tempting in fact that it's part of the
Java language definition.  Uggh!)

3. Having separate writable attributes is offering someone a cannon with
which to shoot their own foot off, as far as having buggy code goes.
(Strictly, this doesn't preclude having a container object where you set the
epoch-second, or set the year, month, day, hour, minute and second all at
once, but even if they're not in the design to begin with, sometime someone
naïve is going to add them.

4. Let's face it, they're pretty small objects. They're on a par with a
"Num", and should get similar treatment.


Reply via email to