I realize I already put down my vote, but I'd like to promote my case after some thought. I guess what we're trying to find out is what's more troublesome and/or surprising:
1. having to set the port explicitly (to #f?) when you want to change the scheme and its port 2. having to set the port explicitly back to its original value if you want to change scheme but not its port I don't think it's unreasonable to expect the user to realize he/she has to change the port if he/she changes the port (as in 1.). That requires an understanding of the relationship between scheme and port by the user. I do, however, think it's more unreasonable to expect the user to realize he/she has to "change" the port back to its original value if he wants to change the scheme but not the port. In this case, you need to understand the internals of uri-common. (You need to understand the scheme-port relationship as well to make sense of the API). I also think it's unfortunate that you cannot simply look at the keywords in update-uri and know exactly which fields are modified by quick glance. Thanks for considering the change :) my vote's on 1. K. On Fri, May 16, 2014 at 3:35 PM, Andy Bennett <andy...@ashurst.eu.org>wrote: > On Friday, 16 May 2014 14:28:51 BST, Andy Bennett wrote: > >> Hi, >> >> If anyone on this mailinglist has strong opinions either way, please let >>> yourselves be heard: now's the time to speak up. >>> >> > The existing behaviour seems reasonable as it only does it when setting > "scheme", not when setting other parts of the URI: > > ----- > #;3> (update-uri (uri-reference "http://localhost:8080/";) scheme: 'https) > #<URI-common: scheme=https port=#f host="localhost" path=(/ "") query=() > fragment=#f> > #;4> (update-uri (uri-reference "http://localhost:8080/";) fragment: > "test") > #<URI-common: scheme=http port=8080 host="localhost" path=(/ "") query=() > fragment="test"> > ----- > > > > > Regards, > @ndy > > -- > andy...@ashurst.eu.org > http://www.ashurst.eu.org/ > 0x7EBA75FF > > _______________________________________________ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users >
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
