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. -Martin
