From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-08-16 21:26:54
> > I would either emphasize it in the docs, or rename the containers to
> > something that reflects this fact (e.g. const_params and mutable_params,
> > as asio does).
> I would much rather emphasize it in the docs, because writing "const"
> and "mutable" over and over is bound to be a chore. Asio gets away
> with it because the mutability of buffers is central to the role of
> asynchronous operations but I'm not so sure the same applies here.
> We are very happy to hear proposals for alternate container names,
> especially if they are complete proposals (give an alternative for
> each existing name) and if necessary what the url_view and url member
> functions would be renamed to.
I would suggest leaving url and url_view as-is, and replacing the "view"
part for "const" for the rest of the containers:
- params stays as is
- params_view becomes const_params
- params_encoded stays as is
- params_encoded_view becomes const_params_encoded
And so on; I'd leave the member function names as they are.
> > I don't know if this is a common use case, but I'd consider adding a function
> > that simplifies it (i.e. params::set_value(string_view key, string_view value).
> Yep, we need that! There are open questions (like what do you do if
> more than one key exists). Here is an open issue for it:
Just commented there.
> > I'm not very keen on exposing the parsing infrastructure and helper
> > functions (other than percent encoding/decoding) as public API,
> > as I think it violates the principle of API surface minimization.
> I feel you there but they have to go somewhere because the
> alternatives are worse. It isn't perfect, I know.
Are the functions intended to be used just by other Boost libraries,
or also the general public? If the former is the case, could they
not be separated into a BSL-licensed repository shared between
libraries and just used as a submodule? I understand you don't want
to put them into a separate Boost library because of the review process
it would involve and the overlapping it would create, but I'd say
a submodule repo could work-around it and not violate any
of the Boost guidelines (AFAIK).
> > The documentation is good and the reference is complete, but I miss
> > some examples.
> Yep. Its not easy to come up with a complete application that just
> does stuff with URLs.
I would find this useful (this builds a QR code using Google's
using namespace boost::urls;
main(int argc, char **argv)
url u ("https://chart.googleapis.com/");
std::cout << u << std::endl;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk