[squeak-dev] Could we have 1 api that work across all of the datish classes?

Chris Cunningham cunningham.cb at gmail.com
Sun Sep 14 05:46:09 UTC 2014


On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <asqueaker at gmail.com> wrote:

> On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham
> <cunningham.cb at gmail.com> wrote:
> > Ok.
> >
> > Date today + 15 days
> > Date today + 1 day
> > ((Date today + 1 day)  - Date today) days
> >
> > That works.  So, does this mean that we should deprecate the following
> > methods in Date so that the observed API doesn't confuse future users?
> > #addDays:, #addMonths:, #subtractDays:, #subtractDate: ?
>
> Well, you won't be able to replicate #addMonths: with the binary
> operators, because how long is "1 month?"  And if we have addMonths:
> then it follows that we would have addDays: and addYears: for
> consistency (I see I have addYears: added in my own personal
> core-extensions package).


Actually, you can add 1 month and 1 year, if you want.  I have proposed
alterations in the InBox that does this - Kernel-cbc.870 and
Collections-cbc.582 (the later of which does not include
Collections-cbc.581).

These collections change #+  in DateAndTime to double-dispatch to the
operand, sending the method #addToDateTime:. This does the same logic on
all objects the previously could be added to a DateAndTime (as tested in
KernelTests-cbc.277).

This allows the introduction of GenericMonth and GenericYear, so that we
CAN do things like
   DateAndTime now + 4 months
This 'GenericMonth' simple holds the number of months that you want to add
(or subtract), and then does the appropriate addition of days based on the
DateAndTime.  It handles different sizes of months, and leap years, just
fine.  SImilarly for GenericYear.

It does make some assumptions on what a 'month' is.
1: If you add a month, you want the result to be in the next calendar
month, never the following one.
2: If you add a month, you want the same day of the month if possible, and
if not (becaue the next month has less days), then the closest that you can
get to it.
3: Similarly, if you subtract a month, you want it in the previous calendar
month, and as close to the starting day of the month as you can get.
4: If you add more than 1 month, you want to end up in the right calendar
month that you would expect, and as close to the starting day of the month
as you can.
5: Similarly with years - next year, same month, same day (or as close as
you can get - February is fun!); same for subtracting.

So, adding 1 month to August 31 would give September 30th; adding 2 months
to August 31 would give October 31st.  And adding 1 month to September 30th
would give October 30th.

I did this because I think a desired API should be as complete and
consistent as we can get it - I really didn't like having to mix the two
(or more) styles:
  DateAndTime now + 1 day
  DateAndTime now addMonths: 1

-cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140913/a642f167/attachment.htm


More information about the Squeak-dev mailing list