Manuscript (Case [Issue]21569) Kernel - DateAndTime should not use respondsTo logic in minus operation

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

Manuscript (Case [Issue]21569) Kernel - DateAndTime should not use respondsTo logic in minus operation

Pharo Issue Tracker
Manuscript Notification
avatar
Cleanup in Project:  Kernel: 1. Pharo Image  •  You are subscribed to this case
Perhaps the conversions to DateAndTime and Duration should not happen implicitly. Right now we have this complex logic because we want to support things like this:

<code>
t := '2004-01-07T11:55:00+00:00' asDateAndTime.
t - 5.
t - '2004-01-07'
</code>

But maybe we shouldn't. It doesn't make much sense to subtract a string or a number (number of what? days? seconds?) from a DateAndTime object. And whoever is using this can easily do an explicit conversion, which, by the way, would also make his code more readable.

<code>
t - 5 asDuration.
t - '2004-01-07' asTimeAndDate
</code>

I've implemented a new version using double dispatch:

<code>
DateAndTime >> - operand
"Subtracts an operand from itself. The operand can be either

another DateAndTime or Duration. In case one DateAndTime is
subtracted from the other, we get the Duration between them.
In case we subtract Duration from DateAndTime, we get another
DateAndTime."
^ operand subtractFromDateAndTime: self.

DateAndTime >> subtractFromDateAndTime: aDateAndTime
"Subtracts itself from another DateAndTime object to find the
duration between them."
^ Duration
seconds: (SecondsInDay * (aDateAndTime julianDayNumberUTC - julianDayNumber))
+ (aDateAndTime secondsSinceMidnightUTC - seconds)
nanoSeconds: aDateAndTime nanoSecond - nanos.

Duration >> subtractFromDateAndTime: aDateAndTime
"Subtracts itself from DateAndTime to get another DateAndTime."
^ aDateAndTime + self negated.
</code>

And I suggest that we mark the previous implementation as deprecated because some code might depend on it.
Priority Priority: 5 – Fix If Time Status Status: Work Needed
Assigned To Assigned to: Everyone Milestone Milestone: Pharo7.0

Go to Case
No longer need updates? Unsubscribe from this case.

Don't want Manuscript notifications anymore? Update your preferences.

Manuscript

_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
https://lists.gforge.inria.fr/mailman/listinfo/pharo-bugtracker