Front page | perl.perl6.language |
Postings from April 2010
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Thread Previous
From:
Mark J. Reed
Date:
April 9, 2010 09:13
Subject:
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Message ID:
l2kf60fe001004090913jcbafc60dnb2dd475cc342037e@mail.gmail.com
Especially since we're not ignoring leap seconds; in UTC, "30 days" is
not always 30*86400 atomic seconds. Other units are more obviously
variable-length, but you have to be careful. If you increment one
month at a time with autocorrect, 4 months from Jan 31 gets you Jun 2
or 3 instead of May 31.
On Friday, April 9, 2010, Mark Biggar <mark@biggar.org> wrote:
> On 4/9/2010 4:53 AM, Moritz Lenz wrote:
>
> Am 09.04.2010 13:34, schrieb Mark J. Reed:
>
> The date still corresponds to an actual day. If I set it to Feb 31, I
> should get back Mar 2 or 3 depending on the year. While I'm having
> trouble thinking of a good specific example, it's a capability I've
> taken advantage of many times, in holiday calculations, calendar
> conversions, and such. I believe it's Python's datetime module that
> has unchecked_* methods for the purpose.
>
> Maybe in p6 the setters could do the correction if the exception is
> resumed?
>
>
> Too much magic. Sounds to me like you want a named parameter for a
> setter, like :force or :unchecked or so.
>
> Anyway, I'm not sure such a feature needs to be in the core, at least
> not in 6.0.0.
>
>
> Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners.
>
> --
> mark@biggar.org
> mark.a.biggar@comcast.net
>
>
--
Mark J. Reed <markjreed@gmail.com>
Thread Previous