Re: [lmi] [lmi-commits] master 1774fba 3/3: Clarify unit-test documentation

[Greg Chicares]

On 5/9/21 4:07 PM, Vadim Zeitlin wrote:
> On Mon,  3 May 2021 16:51:23 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: master
> GC> commit 1774fba8a1003aa902ee17a453fe2a584d34799d
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> 
> GC>     Clarify unit-test documentation
> GC>     
> GC>     It does seem unfortunate that boost's free function
> GC>       path change_extension(path const& p, std::string const& new_ext);
> GC>     was standardized only as non-const member
> GC>       path& replace_extension(path const& new_ext = path());
> GC>     because almost half of lmi's replace_extension() calls
> GC>       $git grep replace_extension
> GC>     must take extra care to preserve the argument, e.g.:
> GC>       fs::path{cell_filepath}.replace_extension(".test")
> GC>     
> GC>     It is tempting to add such a free function, not only for convenience
> GC>     but also for safety.
> 
>  FWIW I hesitated a long time about doing just this, i.e. preserving
> fs::change_path() as a wrapper around std::filesystem::replace_extension()
> and continuing to use it instead of replacing all of its occurrences and I
> think I even still have a commit where I had actually done it.
> 
>  But, finally, I decided that it would be too confusing to have a function
> looking and smelling like a standard one, but not being standard, so I
> didn't do it. If we do decide to add such a function, I think it would be
> nice to make it obviously different from the similar standard functions,
> e.g. by calling it fs::lmi::change_extension().

In cases like this, I've found it best to write out my concerns,
and then reconsider them after some days have passed, and after
discussion. Today, it seems to me that the Committee's choice was
unfortunate, but that's beside the point: their choice wasn't so
bad that we must anathematize it, and doing anything different in
lmi would just be weird, like writing our own string class.

>  BTW, I never know if I should ask you about decisions like this (and risk
> wasting your time) or just decide on my own and let you change it later if
> you don't like the decision I've taken (and risk wasting even more of your
> time). I don't think there is a universal answer to this question, but
> maybe there is at least some heuristic I could use?

I think you've found it already: make decisions that seem right
to you, and I'll probably agree with most of them. This particular
case is really hard, and already I look back on the paragraph I
just wrote above and want to disagree with it. But I'm certain
that I don't want to add an lmi alter_extension() today.