Could we have 1 api that work across all of the datish classes?

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

Could we have 1 api that work across all of the datish classes?

cbc
at least adjusting the date portions?  We currently have:

Date - #addDays:, #subtractDays:
TimeStamp - #plusDays:, #minusDays:
DateAndTime - #+ and #-

 I keep getting messed up by which type of object I have, and which method it understands to alter the date portion.

Would the community be interested in having these methods spread out to all of the types so that we can have more polymorphic date representations?  (and, maybe, even the rest of the protocols?)

Or, alternatively, removing some of the options and settling on one standard?

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

Chris Muller-3
Just use the binary operators.

myDate + 3 days.
myDate - 3 days.
myDateAndTime + 3 days.
myDateAndTime - 3 days.
3 days fromNow.
3 days ago.

Finally, TimeStamps are deprecated, don't use them.

On Fri, Sep 12, 2014 at 9:59 AM, Chris Cunningham
<[hidden email]> wrote:

> at least adjusting the date portions?  We currently have:
>
> Date - #addDays:, #subtractDays:
> TimeStamp - #plusDays:, #minusDays:
> DateAndTime - #+ and #-
>
>  I keep getting messed up by which type of object I have, and which method
> it understands to alter the date portion.
>
> Would the community be interested in having these methods spread out to all
> of the types so that we can have more polymorphic date representations?
> (and, maybe, even the rest of the protocols?)
>
> Or, alternatively, removing some of the options and settling on one
> standard?
>
> -cbc
>
>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

cbc
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: ?

Also, TimeStamp is not marked as deprecated in any way at all - no comment, no other marking.  Although I normally wouldn't have noticed, since I have ODBC loaded which loads a completely different TimeStamp (with Magnitude superclass instead of DateAndTime like the default TimeStamp in Trunk).  Which means it should probably be patched to use a more normal TimeStamp representation.

On Fri, Sep 12, 2014 at 8:16 AM, Chris Muller <[hidden email]> wrote:
Just use the binary operators.

myDate + 3 days.
myDate - 3 days.
myDateAndTime + 3 days.
myDateAndTime - 3 days.
3 days fromNow.
3 days ago.

Finally, TimeStamps are deprecated, don't use them.

On Fri, Sep 12, 2014 at 9:59 AM, Chris Cunningham
<[hidden email]> wrote:
> at least adjusting the date portions?  We currently have:
>
> Date - #addDays:, #subtractDays:
> TimeStamp - #plusDays:, #minusDays:
> DateAndTime - #+ and #-
>
>  I keep getting messed up by which type of object I have, and which method
> it understands to alter the date portion.
>
> Would the community be interested in having these methods spread out to all
> of the types so that we can have more polymorphic date representations?
> (and, maybe, even the rest of the protocols?)
>
> Or, alternatively, removing some of the options and settling on one
> standard?
>
> -cbc
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

Chris Muller-3
On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham
<[hidden email]> 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).

> Also, TimeStamp is not marked as deprecated in any way at all - no comment,

I know it needs to be commented for 4.6 release so we can eventually
get it out of the base image.  There might still be one or two users
that need conversion to DateAndTime.

> no other marking.  Although I normally wouldn't have noticed, since I have
> ODBC loaded which loads a completely different TimeStamp (with Magnitude
> superclass instead of DateAndTime like the default TimeStamp in Trunk).
> Which means it should probably be patched to use a more normal TimeStamp
> representation.
>
> On Fri, Sep 12, 2014 at 8:16 AM, Chris Muller <[hidden email]> wrote:
>>
>> Just use the binary operators.
>>
>> myDate + 3 days.
>> myDate - 3 days.
>> myDateAndTime + 3 days.
>> myDateAndTime - 3 days.
>> 3 days fromNow.
>> 3 days ago.
>>
>> Finally, TimeStamps are deprecated, don't use them.
>>
>> On Fri, Sep 12, 2014 at 9:59 AM, Chris Cunningham
>> <[hidden email]> wrote:
>> > at least adjusting the date portions?  We currently have:
>> >
>> > Date - #addDays:, #subtractDays:
>> > TimeStamp - #plusDays:, #minusDays:
>> > DateAndTime - #+ and #-
>> >
>> >  I keep getting messed up by which type of object I have, and which
>> > method
>> > it understands to alter the date portion.
>> >
>> > Would the community be interested in having these methods spread out to
>> > all
>> > of the types so that we can have more polymorphic date representations?
>> > (and, maybe, even the rest of the protocols?)
>> >
>> > Or, alternatively, removing some of the options and settling on one
>> > standard?
>> >
>> > -cbc
>> >
>> >
>> >
>>
>
>
>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

cbc
On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <[hidden email]> wrote:
On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

Bert Freudenberg

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <[hidden email]> wrote:
On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham
<[hidden email]> 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

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

- Bert -






smime.p7s (5K) Download Attachment
cbc
Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

cbc
On Sun, Sep 14, 2014 at 10:03 AM, Bert Freudenberg <[hidden email]> wrote:

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <[hidden email]> wrote:
On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham
<[hidden email]> 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

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

That would be neat, but not straight-forward.  For instance, 1 month + 1 day is no necessarily the same as 1 day + 1 month!  At least, not with the expectations given before.  Specifically:

August 30th + 1 month + 1 day = October 1st.
August 30th + 1 day + 1 month = September 30th.

Similarly, I think you can run into trouble with ordering of years and months (around Leap years, mainly), but I haven't worked that out yet.

Maybe a third type of duration - that can take a sequence of additive (subtractive) durations, and apply them together later.

But maybe I'm missing a point - what would you want to get our of (1 year + 1 month + 1 week + 1 day)?  What questions would you ask of such a thing?  Remember, once you get into months and years, they are unspecific until given the context of a real month and or year.  A month is anywhere from 28 to 31 days (and possibly an extra second or similar); a year is 365 or 366 days.

-Chris
 

- Bert -









Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

Bert Freudenberg

On 15.09.2014, at 18:10, Chris Cunningham <[hidden email]> wrote:

On Sun, Sep 14, 2014 at 10:03 AM, Bert Freudenberg <[hidden email]> wrote:

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

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.

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

That would be neat, but not straight-forward.  For instance, 1 month + 1 day is no necessarily the same as 1 day + 1 month!  At least, not with the expectations given before.  Specifically:

August 30th + 1 month + 1 day = October 1st.
August 30th + 1 day + 1 month = September 30th.

Similarly, I think you can run into trouble with ordering of years and months (around Leap years, mainly), but I haven't worked that out yet.

Maybe a third type of duration - that can take a sequence of additive (subtractive) durations, and apply them together later.

You're right, that's how it should work.

But maybe I'm missing a point - what would you want to get our of (1 year + 1 month + 1 week + 1 day)?  What questions would you ask of such a thing?  Remember, once you get into months and years, they are unspecific until given the context of a real month and or year.  A month is anywhere from 28 to 31 days (and possibly an extra second or similar); a year is 365 or 366 days.

I guess it would just be for aesthetic reasons, ensuring that (a + b) + c  = a + (b + c).

- Bert -






smime.p7s (5K) Download Attachment
cbc
Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

cbc


On Mon, Sep 15, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:

On 15.09.2014, at 18:10, Chris Cunningham <[hidden email]> wrote:

On Sun, Sep 14, 2014 at 10:03 AM, Bert Freudenberg <[hidden email]> wrote:

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

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.

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

That would be neat, but not straight-forward.  For instance, 1 month + 1 day is no necessarily the same as 1 day + 1 month!  At least, not with the expectations given before.  Specifically:

August 30th + 1 month + 1 day = October 1st.
August 30th + 1 day + 1 month = September 30th.

Similarly, I think you can run into trouble with ordering of years and months (around Leap years, mainly), but I haven't worked that out yet.

Maybe a third type of duration - that can take a sequence of additive (subtractive) durations, and apply them together later.

You're right, that's how it should work.

Do you have a proposal for what to call this thing?  I'd be likely to call it something like 'SequenceOfDurations'.  Which I'm not really fond of.
-cbc
But maybe I'm missing a point - what would you want to get our of (1 year + 1 month + 1 week + 1 day)?  What questions would you ask of such a thing?  Remember, once you get into months and years, they are unspecific until given the context of a real month and or year.  A month is anywhere from 28 to 31 days (and possibly an extra second or similar); a year is 365 or 366 days.

I guess it would just be for aesthetic reasons, ensuring that (a + b) + c  = a + (b + c).

- Bert -









Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

Bert Freudenberg

On 15.09.2014, at 23:05, Chris Cunningham <[hidden email]> wrote:



On Mon, Sep 15, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:

On 15.09.2014, at 18:10, Chris Cunningham <[hidden email]> wrote:

On Sun, Sep 14, 2014 at 10:03 AM, Bert Freudenberg <[hidden email]> wrote:

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

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.

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

That would be neat, but not straight-forward.  For instance, 1 month + 1 day is no necessarily the same as 1 day + 1 month!  At least, not with the expectations given before.  Specifically:

August 30th + 1 month + 1 day = October 1st.
August 30th + 1 day + 1 month = September 30th.

Similarly, I think you can run into trouble with ordering of years and months (around Leap years, mainly), but I haven't worked that out yet.

Maybe a third type of duration - that can take a sequence of additive (subtractive) durations, and apply them together later.

You're right, that's how it should work.

Do you have a proposal for what to call this thing?  I'd be likely to call it something like 'SequenceOfDurations'.  Which I'm not really fond of.

How about GenericDuration, to keep with the theme?

- Bert -






smime.p7s (5K) Download Attachment
cbc
Reply | Threaded
Open this post in threaded view
|

Re: Could we have 1 api that work across all of the datish classes?

cbc

On Tue, Sep 16, 2014 at 8:27 AM, Bert Freudenberg <[hidden email]> wrote:

On 15.09.2014, at 23:05, Chris Cunningham <[hidden email]> wrote:



On Mon, Sep 15, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:

On 15.09.2014, at 18:10, Chris Cunningham <[hidden email]> wrote:

On Sun, Sep 14, 2014 at 10:03 AM, Bert Freudenberg <[hidden email]> wrote:

On 14.09.2014, at 07:46, Chris Cunningham <[hidden email]> wrote:

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.

This sounds surprisingly reasonable to me ;-)

I love using Squeak interactively, and these messages appear to do "what I'd expect".

The only objection I'd have would be that it's not general enough: if you rolled GenericMonth and GenericYear into one and added in a regular duration, we could get something reasonable out of an expression like (1 year + 1 month + 1 week + 1 day).

That would be neat, but not straight-forward.  For instance, 1 month + 1 day is no necessarily the same as 1 day + 1 month!  At least, not with the expectations given before.  Specifically:

August 30th + 1 month + 1 day = October 1st.
August 30th + 1 day + 1 month = September 30th.

Similarly, I think you can run into trouble with ordering of years and months (around Leap years, mainly), but I haven't worked that out yet.

Maybe a third type of duration - that can take a sequence of additive (subtractive) durations, and apply them together later.

You're right, that's how it should work.

Do you have a proposal for what to call this thing?  I'd be likely to call it something like 'SequenceOfDurations'.  Which I'm not really fond of.

How about GenericDuration, to keep with the theme?

That sounds resaonable.  I'll add it in in the next day or two (when I get a couple of hours) and add comments as well - this class definitely deserves it (and the other two should have comments as well).

- Bert -