[racket-dev] racket/date, SRFI-19, date construction

On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:

> On 2013-01-11 20:35:50 -0600, Robby Findler wrote:
> >    (The diff shows all of the tests changing). Are the tests for exported
> >    functions? If so, that sound bad.
>
> Only a subset of the string->date tests should have changed in the diff
> (which is how it shows up in my mail reader).
>
>
Oh, I see. These tests all appear to be about the item below we're debating
(right?).


> >    Was the mutation exposed via the library?
>
> No, it wasn't.
>
> >    That sounds like a backwards incompatible change (in that some
> programs
> >    that could use srfi/19 would get #f out of selectors that now get
> >    something else).
> >    Could a srfi/19 date be a union of two structs, where one represented
> a
> >    time only?
>
> Potentially yes, but then it wouldn't be a Racket date struct. Also, I
> think the implementation of srfi/19 was actually violating its
> documented interface by allowing booleans to show up in these fields.
>
>
I think backwards compatibility here is probably more important than it
producing a racket date. Is there some reason not to think so? I believe
this library gets used a lot.

Maybe the parsing function could accept keyword optional arguments to say
which day to use if one isn't specified? And if a date isn't specified,
you'd get back a srfi/19 time struct instead of a racket date struct in
this case (but where the other srfi/19 accessors return '#t's when they get
time structs).

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130111/fb80d35d/attachment.html>