Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Tue, 30 Jul 2019, Junio C Hamano wrote:
>
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>>
>> > +#define UPDATE_DEFAULT(s,v) do { if (s == -1) { s = v; } } while(0)
>>
>> [...]
>> 3. When we learn to set default values for variables that are not
>> boolean in the future, we will regret that we did not name it
>> UPDATE_DEFAULT_BOOL(slot, value).
>
> On the other hand, as we never promised any kind of API (and this is not
> even an internal API to begin with), it will be _easy_ to rename it in
> the unlikely event that we would ever introduce non-boolean defaults to
> override, wouldn't you agree?
I agree that it is easy to say that it is easy to rename it later
and burden somebody else with the task.
I know that the renaming itself is easy, when you limit yourself
within the scope of a single topic, whether done now or later. I
also know that having to worry about other topics in flight has
non-zero cost. I also know that you are not the one who will bear
it---I will be.
So from my point of view, if we can make a prediction, even with
limited knowledge that a name may need to be renamed in the future,
it is better not pick such a name and instead use one that we think
it has a better chance of surviving without needing a rename.
