TimeStamp copy: Bug or feature?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TimeStamp copy: Bug or feature?

Dmitry Zamotkin-2
Here is code:

ts1 := TimeStamp current.
ts2 := ts1 copy.

ts1 addSeconds: 100.
ts1 = ts2 "true"

Is it all right?


Dmitry Zamotkin


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp copy: Bug or feature?

Dmitry Zamotkin-3
> Here is code:
>
> ts1 := TimeStamp current.
> ts2 := ts1 copy.
>
> ts1 addSeconds: 100.
> ts1 = ts2 "true"
>
> Is it all right?
>
>
> Dmitry Zamotkin

Sorry, I've missed TimeStamp>>addSeconds: method

addSeconds: aNumber
 ^ self class fromSeconds: (self asSeconds + aNumber).

There is the same behaviour in Date and Time classes:

"test Time"
time := Time now.
timeCopy := time copy.
time addTime: (Time fromSeconds: 100).

time = timeCopy "true"

"test Date"
date := Date today.
dateCopy := date copy.
date addDays: 100.

date = dateCopy "true"

Dmitry


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp copy: Bug or feature?

Ian Bartholomew-4
In reply to this post by Dmitry Zamotkin-2
Dmitry,

> ts1 := TimeStamp current.
> ts2 := ts1 copy.
>
> ts1 addSeconds: 100.
> ts1 = ts2 "true"
>
> Is it all right?

#addSeconds: is not part of the current Dolphin image so it depends on the
implementation of that but the code looks right and is in keeping with the
Time and Date hierarchy.

Time and Date are immutable. Once you have created an object for one of
these classes it's value cannot be changed. This is why there are no
instance side setter methods. All the #addXXX and #subtractXXX methods in
Date and Time should answer new instances of the receiver class and should
not alter the value of the receiver.

A TimeStamp is mutable but you can only change it's Time or Date for a
new Time or Date, you can't modify the existing value.

Depending on what your code above was trying to achieve you might have
wanted something like -

ts1 := TimeStamp current.
ts2 := ts1 copy.
ts1 time: (ts1 time addTime: (Time fromSeconds: 100)).
ts1 = ts2

FWIW. I've just had a look at my recently downloaded VWNC and it does have
an TimeStamp>>addSeconds: which does answer a new TimeStamp object, so in VW
you could do

ts1 := Timestamp now.
ts2 := ts1 copy.
ts1 :=  ts1 addSeconds: 100.
ts1 = ts2

Regards
    Ian


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp copy: Bug or feature?

Dmitry Zamotkin-3
"Ian Bartholomew" <[hidden email]> wrote in message
news:gSoQ6.109282$[hidden email]...

> ts1 := TimeStamp current.
> ts2 := ts1 copy.
> ts1 time: (ts1 time addTime: (Time fromSeconds: 100)).
> ts1 = ts2

Pardon, it does not work, Ian:

ts1 := TimeStamp date: (Date fromString: '01.01.2000') time: ( Time
fromString: '23:59:59').
ts2 := ts1 copy.
ts1 time: (ts1 time addTime: (Time fromSeconds: 2)).

ts1 "0:00:01, 1 january 2000"


Dmitry


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp copy: Bug or feature?

Dmitry Zamotkin-3
In reply to this post by Ian Bartholomew-4
"Ian Bartholomew" <[hidden email]> wrote in message
news:gSoQ6.109282$[hidden email]...
> Time and Date are immutable. Once you have created an object for one of
> these classes it's value cannot be changed. This is why there are no
> instance side setter methods. All the #addXXX and #subtractXXX methods in
> Date and Time should answer new instances of the receiver class and should
> not alter the value of the receiver.

Thanks, it was my shortsightedness :(((

Dmitry