On Thu, Sep 18, 2014 at 11:49 PM, Chris Cunningham
<cunningham.cb at gmail.com> wrote:
> On Mon, Sep 15, 2014 at 4:04 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>> On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham
>> <cunningham.cb at gmail.com> wrote:
>> > This changes adds test for things like
>> > DateAndTime now + 2 days
>> > and
>> > DateAndTime now + 2
>> > (the later of which adds two nanoSeconds - who would have guessed?)
>
> ...
>>
>> > 4> A failure in TestSubtractTimespan.  Currently, Squeak treats adding a
>> > Timespan to the DateAndTime as adding the span of time represented by
>> > Timespan to the DateAndTime.  It treats subtracting the same as if you
>> > wanted the difference between the DateAndTime and the first (starting)
>> > dateAndTime of the TimeSpan.  I would assume what is really wanted would
>> > be
>> > to subract the space of time from the DateAndTime instead.  Does anyone
>> > dissagree with this desire?
>>
>> No.  I mean, yes, I disagree.  Timespans represent points-in-time of a
>> particular duration (as you know).  Just as adding two DateAndTime's
>> together doesn't make a lot of sense, but *subtracting* them does,
>> subtracting a TimeSpan from a DateAndTime makes sense but adding a
>> TimeSpan was made to be "conveniently" sensible.  Neither one is
>> wrong, but there is a lot of code where the interplay between Dates
>> and DateAndTime's might be expected to behave similarly as
>> DateAndTime's with other DateAndTime's.  For example:
>>
>>    DateAndTime now - purchaseDate > 90 days ifTrue: [ ^ 'Warranty expired'
>> ].
>>
>> where purchaseDate is a Date.  Its very reasonable to expect for the
>> other Timespan types like
>>
>>     DateAndTime now - ('3/1/2014' asMonth)
>>
>> to subtract the start of March, 2014 from #now.  Changing or
>> redefining that behavior to subtract the duration is not any more
>> sensible than treating it as the start, but would break a lot of code.
>>
> Hi Chris, yes, this looks right.  I had just looked at Timespan without
> looking at its subclasses, and tried building one like:
>     Timespan starting: Date today duration: 3 days
>  Building it this way isn't as obvious as, say, Date today (which is
> definitely something I'd like to compare against the start!).
>
> The subclass Schedule is kinda odd - we'll check the different between the
> date and the start of the schedule, but it still make sense IF it is
> documented that way.
>
> In line with the other suggestion - basically expecting errors for
> odd/unexpected combinations (like expecting the string to be a date/time for
> subtracting, and a time/duration string for addition), what do you think
> about adding Timespans or DateAndTimes to durations, such as:
> 1 hour + DateAndTime now
> ?  It tries to just add the duration part of the second operand tot he
> duration - which is weird.  So:

Hmmm...  that's a tough one.  And not because its not commutative, but
simply that it MIGHT be useful to be able to add the current time to a
Duration.

Maybe we should determine the answer by asking ourselves, if someone
wanted to add a duration to the current time of day, how would it be
done?  It looks like they would need to simply write:

  1 hour + DateAndTime now asDuration

which is more explicit.  So, I think it would probably be fine to make
"1 hour + DateAndTime now" produce an error, because implicit code is
generally worse than explicit.

> Date today + Date today = Date today
> I would think these should raise errors as well.

Hmm, yeah, again the user explicitly access the #duration, as in:

  Date today + Date today duration

I'm slightly nervous that erroring on aTimespan + anotherTimespan
would eliminate some kind of flexibility in some sophisticated app.
But for everything else, it really seems like the code using the
Chronology should be required to be more explicit..  I would say, lets
go for it.  Produce an error and let apps, if any, tell us why they
think they would want to do that.   :)

> And thank YOU for sending me off on this path int he first place, and for
> the considered reply to what I'm trying to do.

No, thank YOU!  :)  We're all here because we enjoy analyzing and
improving this stuff..