Re: Boost.URL review

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-24 15:37:19

On Wed, Aug 24, 2022 at 7:59 AM Zach Laine via Boost
<boost_at_[hidden]> wrote:
> This seems to be the heart of the matter.  I expect params to be a
> real flat_map or map or sorted vec, and it's not.

Yeah, I see what you mean. "params" sounds like its a first-class
object, but it isn't.

> If my expectation is wrong because of the lack of a _view suffix in
> the name, that's fine -- but please add that to make things clear.

There are 8 containers which need names:

    segments
    segments_view
    segments_encoded
    segments_encoded_view
    params
    params_view
    params_encoded
    params_encoded_view

We prefix the type name with the type of element "segment" or "param",
so that it sorts nicely. We could have went with "encoded_segments"
which also makes sense but then they don't group together as well and
it hurts discoverability in the docs (Ramey Rule).

The _encoded suffix is self-explanatory. We chose the suffix _view to
distinguish from the read-only containers from the mutating ones.
Someone suggested putting "const" and "mutable" in the name but in my
opinion that is ugly:

    const_segments_view
    mutable_segments_view
    const_encoded_segments_view
    mutable_encoded_segments_view
    const_params_view
    mutable_params_view
    const_params_view
    mutable_params_view

> However, the _view  suffix in std C++ is used exclusively for immutable
> types, so maybe something else is indicated, like _facade or some
> variation of span.

As if we didn't have a hard enough time coming up with 8 names that
have synergy and aesthetics :) How about the suffix _ref?

    segments_ref
    segments_cref
    segments_encoded_ref
    segments_encoded_cref
    params_ref
    params_cref
    params_encoded_ref
    params_encoded_cref

Or we could mix _ref and _view?

    segments_ref
    segments_view
    segments_encoded_ref
    segments_encoded_view
    params_ref
    params_view
    params_encoded_ref
    params_encoded_view

We did the best we could with the current names and I know they aren't
perfect. We're more than happy to hear feedback on whether any of
these alternatives are resonating with folks, or if someone wants to
propose a new set of 8 identifier names.

Thanks