Re: Boost.URL review

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2022-08-24 17:16:02

For this case, I definitely prefer ref to view.

Zach

On Wed, Aug 24, 2022 at 10:37 AM Vinnie Falco <vinnie.falco_at_[hidden]> wrote:
>
> 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