(I think it is okay.) But here's a chance for me to point out something I heard about in a conversation with Satnam Singh at OOPSLA about how Google works that it seems like would be a nice fit for us. Here's my adaptation to our world: when you push out what some might consider a change that breaks clients (like this one where you also hope to avoid a new package) you are obliged to submit pull requests on all ring-0 packages to (at a min) get all test cases to pass.
I guess you did that here, at least for the ring-0 packages in the racket git repo, which is where the "I found ..." comment comes from? Robby On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > Currently, `(define-serializable-struct id ....)` expands to `(provide > deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to > be exported to make things work, but the export is a hassle: the > programmer doesn't care about it, it's not usually documented, > re-exporting modules don't want to re-export it, and so on. > > I'm planning to change `define-serializable-struct` so that the export > is put in a `deserialize-info` submodule, where it should cause less > trouble. This is a slightly backward-incompatible change; I found a > couple of modules that explicitly excluded `deserialize-info...` on > import, and so those exclusions would have to be dropped. > > The change could also be backward-incompatible by changing the protocol > for providers of deserialization other than `define-serializeable-struct`. > That problem is easier to address: `deserialize` can try a > `deserialze-info` submodule first, and if the export isn't found, then > it can try the original module. > > Ok? > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
