Mathieu Bouchard wrote:
>On Mon, 26 Feb 2001, Kevin Smith wrote:
>> I guess I don't understand the issue. What code 
>> would break if Time becomes mutable?
>
>Old code that assumes that Time is immutable, when it enters in contact 
>with new code that assumes that the code it works with assumes Time is
>mutable. (has to do with to call dup or not to call dup.)

Ok. I still don't really understand how any real 
code would be this dependent on immutability, but 
I'm willing to take your word for it.

>I think I could think otherwise if I'd know a strong enough reason to make
>the change, and I think I don't. 

The example that was raised seemed to point out 
the need to me, but I guess there's another 
approach. Rather than having MyTime inherit from 
Time, it could delegate to it. That allows things 
like MyTime t = t.new; t += tenSeconds.

However, it requires extra effort to expose each 
of the public methods of Time through the MyTime 
interface. It is doable, so my RCR is not 
critical.

Hmmmm. Back to the original suggestion. When you 
have a string and call << I assume the string is 
'muted' (changed). Similarly, when you have an 
Integer and call += the integer is changed. To 
me, Time seems to fall into this same category of 
object, and thus I would expect it to be 
mutable.

I would like to be able to add some seconds to a 
time, adjust the hour of a time without affecting 
the other fields, etc. Perhaps that's just me.

Kevin