Here is my current plan: Add web-server/compat/0 directory with, e.g., web-server/compat/0/http/response-structs to hold compatibility bindings to bridge the old http/response-structs and the new http/response-structs
In that directory is the attached README. What do you think? Jay On Tue, Nov 30, 2010 at 11:14 AM, Eli Barzilay <e...@barzilay.org> wrote: > Three hours ago, Robby Findler wrote: > > On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay <e...@barzilay.org> wrote: > > > Two hours ago, Robby Findler wrote: > > >> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay <e...@barzilay.org> > wrote: > > >> > > > >> > The problem here is that there is no name to change -- it's the > > >> > implicit "coercion" of xexpr values to a response. > > >> > > >> Why can't there be two libraries, one that coerces and one that > > >> doesn't? More generally, one that acts the same as the current > > >> library and one that is intended for new code? > > > > > > That would require a new `web-server' module, as well as a whole > > > bunch of other modules. > > > > I know. > > > > > Even worse, writing a module using one web server library, and > > > using it in the other won't work, since it's a dynamic property of > > > how the result is getting used. > > > > (I think it may be possible to be creative to avoid these things being > > errors when you mix; but maybe it is better to have an error when you > > mix; I don't have a strong opinion here but I'd try to make mixing > > work so people can migrate piecemeal.) > > [I don't see a way to do that.] > > > > As I said before, we have done this with the class system many > > times. We have done this with other parts of the system as well > > (not as many times tho). It is not a simple thing. > > > > That said, massive backwards incompatibility as Jay is proposing > > seems wrong. > > I'll leave this Jay, but I think that there are some important points: > > * Doing the same for the web server will be much more problematic > since there are many interface modules that do the implicit > coercion. It looks to me like the only way to do that will be a new > toplevel `web-server' collection. > > * Even in the case of the class system, one of the transitions was > going the other way -- renaming the old one (still available as > `mzlib/class100') instead of having the new one under a new name. > > * The fact that this is much more problematic in the web server's > case, combined with the fact that the change itself is much more > minor (compared to the class system changes), is -- IMO -- a strong > indication that a backward-compatible change via a parameter is the > right way to go (defaulting to the same as it does now). > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93
README
Description: Binary data
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
