On Tue, 2019-08-27 at 10:15 -0500, Eric Sandeen wrote:
> On 8/27/19 10:10 AM, Darrick J. Wong wrote:
> > > Eric's comments aside, it would be nice to have some consistency
> > > between
> > > the various result.negated checks (i.e. 'if (negated)' vs 'if
> > > (!negated)').
> > Frankly I'd prefer "if (result.enabled)" or something affirmative
> > so I
> > don't have to twist my brain around !negated == MAIN SCREEN TURN
> > ON.
> >
> > --D
>
> I think it's probably possible to just keep explicit Opt_ikeep /
> Opt_noikeep
> and dispense with the whole negated/enabled parsing, unless there's a
> downside
> to doing that. Not quite sure what's best, but it also exposes the
> inconsistency
> we have with flag-ish options - some have negation of defaults as
> well as ability
> to restate defaults, others don't. (i.e. we have nouuid but not
> "uuid,"
> norecovery but not "recovery," but we have ikeep/noikeep,
> attr2/noattr2...)
As far as I know there's nothing that mandates using the type
that marks these as having a corresponding "no" option.
Not using it would also eliminate my compultion to always have
the short block in "if () {} else {}" first (at least mostly).
I'll do that when I'm fixing up the problems Eric has described.
Thanks Eric and Brian (and for that matter, Darrick too) for spending
time looking at the patches.
btw, I will get around to replying to the comments that have been
made, just not straight away, since I want to have a look at the
option parsing problem that Eric has seen first.
Ian
