On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa <as...@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
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
