Oh, right. Pattern matching on url structs. If we want to keep that working (which I think we do), then that ties our hands much more.
I believe there are some other crufty things in net/url (having to do with encodings?). Does it make sense to have a new library that does all of this right from the start and then announce that we're going to stop supporting net/url in a year or so, in favor of the new library? I see there is no net/http. so we could also do a better job with the whole simple-script-for-downloading-a-file-over-http and perhaps other things along those lines? Robby On Wed, Nov 23, 2011 at 12:05 PM, Jay McCarthy <[email protected]> wrote: > I thought about that too since there are few instances where people pattern > match on the URL struct. What would be a good name for the new field... > url-maybe-query? > > On Wed, Nov 23, 2011 at 11:02 AM, Robby Findler > <[email protected]> wrote: >> >> I don't think we want to change how the current url struct selectors >> work when applied to url structs. >> >> You could probably get away with changing the url struct if you could >> provide functions that act the way the old selectors used to work -- >> does that help? >> >> Robby >> >> On Wed, Nov 23, 2011 at 12:00 PM, <[email protected]> wrote: >> > jay has updated `master' from 6a99c93ebb to 9d8d36e568. >> > http://git.racket-lang.org/plt/6a99c93ebb..9d8d36e568 >> > >> >> > >> > 7f9818b Jay McCarthy <[email protected]> 2011-11-23 10:35 >> > : >> > | This fixes 10497 and potentially breaks programs that assume the query >> > of a URL is always a list. I have fixed uses in the Web Server, which I >> > expect is the major thing affected, but much more could be. Therefore I am >> > skeptical this is a good idea just for the representation of ?. So, I'd >> > like >> > other people to review the change and let me know if they think I should >> > revert it. >> > : > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
