lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 1774fba 3/3: Clarify unit-test documentation
Date: Sun, 9 May 2021 18:07:44 +0200

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().

 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? If so, I'd b every
grateful if you could share it with me because I also spent quite some time
thinking about whether I should ask you or not about this choice (although
at least not as much as thinking about the choice itself, so this series
finally converged and I could finish in finite, although awfully long,
time).

 Regards,
VZ

Attachment: pgpwZ61a26a1o.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]