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

Chris Muller asqueaker at gmail.com
Fri Sep 12 15:54:50 UTC 2014


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).

> 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 <asqueaker at gmail.com> 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
>> <cunningham.cb at gmail.com> 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
>> >
>> >
>> >
>>
>
>
>
>


More information about the Squeak-dev mailing list