Akihiko Odaki <akihiko.od...@daynix.com> writes: [...]
> Let me go back to the discussion of the bool/OnOffAuto problem below: > > The values the command line syntax accepts are on/yes/true/y and > off/no/false/n. > > For the command line syntax, you can always use on/off whether the type is > bool or OnOffAuto. In my opinion, it is still not good to reject yes/true/y > and no/false/n for OnOffAuto; why do we suddenly reject them when the > property gets the "auto" value? As you pointed out, the usage of enum is our > internal concern and should not bother users. The command line is a different mess. For better or worse (worse if you ask me), we added code to accept additional syntax for bool values. Doing the same for enums that happen to have some values that look boolean at a glance is in my opinion a terrible idea. We have at least two: OnOffAuto and OnOffSplit. But let's get back to QMP. > The situation is worse for JSON as there is no common literals that are > compatible with both of bool and OnOffAuto, which forces users to remember > the type. JSON is primarily for machines, and machines are very good at remembering the type. An argument can be made that OnOffAuto is problematic interface design. In fact, I made it; see "managed to maneuver ourselves into a bit of a corner" upthread. > So I think this patch makes sense in terms of usability. Accepting multiple > representations for one value is ugly, but it is better than exposing the > ugliness to users. We should deprecate the representations except one if we > really hate the ugliness. I believe churn & complexity outweigh the benefits.
