[PATCH 2 of 7 v3 flags] fancyopts: disallow true as a boolean flag default (API)
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Fri Sep 16 10:58:51 EDT 2016
On 09/16/2016 04:33 PM, Augie Fackler wrote:
>
> On Fri, Sep 16, 2016 at 10:29 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
>
> On 09/14/2016 05:11 AM, Augie Fackler wrote:
>
> # HG changeset patch
> # User Augie Fackler <augie at google.com
> <mailto:augie at google.com>>
> # Date 1472584421 14400
> # Tue Aug 30 15:13:41 2016 -0400
> # Node ID 828f260114a3a55e246cb5de434e75bdc782e4ad
> # Parent 600be3c9acee0ec14bd19c032cc0480e4501fe8c
> fancyopts: disallow true as a boolean flag default (API)
>
> This was nonsense, as there's not been a way for the user to
> un-specify the flag. Restricting this behavior will open
> the door to
> some nice fit-and-finish functionality in a later patch,
> and shouldn't
> break any third party extensions. This is marked as
> (API) since it
> might break a third party extension, but given the fact
> that it was
> silly before that's mostly a formality.
>
>
> I really wish we had details on this as requested in the
> review of the previous version. Especially because I
> remember that forbidding 'True' as default was making other
> improvement hard so I'm not sure why we have to do this.
>
>
> Err? I'm not sure what you're asking for now, and I definitely
> didn't understand it on the last go round.
>
>
> Okay, let me clarified, My question here is:
>
> Why is this problematic to have default to 'True Value'
>
>
> You refered this as """These cases are a bit problematic, because we
> don't really have a way to specify default-true flags""" in
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/087968.html
> <https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/087968.html>
>
> I'm seeing another avatar of this question when you says
> "Restricting this behavior will open the door to some nice
> fit-and-finish functionality in a later patch" in the current
> thread. I would like details on this "nice fit-and-finish" features.
>
> Does this clarify my question ?
>
>
>
> Sure. The answer (which I can fold into the log message if you think
> it's important) is that because of how opts make it into diffopts, we
> can't rely on opts to not be filled in for a value that was unspecified
> on the command line. Because of that, we need to find a backwards
> compatible way to thread defaults through such that they can be
> identified as defaults. The easy way out is to use None for default and
> False for explicitly-false.
Yes please, fold it into the commit message. This this have been
confusing me for the last versions this will probably be useful to other.
> I'm open to other solutions on the tri-state, but it's a significant
> piece of work that I don't really want to take on.
Getting the handle of tri-state right in a way to do not install a
future complex rework for the 'default' to True case seems important to
me. The amount of work involved does not appear too daunting to me.
Cheers,
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list