On 2014-03-09 09:55-0000 Andrew Ross wrote: > On Fri, Mar 07, 2014 at 05:46:05PM -0800, Alan Irwin wrote: >> On 2014-03-07 10:06-0000 Andrew Ross wrote: >> >>> >>> I was just going to go ahead and change example 8 to use >>> the sombrero function by default. This reminded me of a >>> long running "feature" of plplot which I have found irksome >>> in the past, namely that boolean command options can only >>> set an option to true (1) not false (0). >> >> Perhaps I am missing something, but wouldn't it be straightforward to >> implement such options exactly like we implement driver options, >> where, for example, we can set -drvopt text_clipping=0 or -drvopt >> text_clipping=1 for the xcairo device? > > You could do in this way, but that would require more recoding. It is as > much a matter of principle that it seems perverse to have a boolean flag > which you can switch on, but not off.
OK. I think I understand now. Therefore, I like the first half of (1) which to repeat what you said is > 1) Automatically add a command line option -noopt for every > boolean command line option -opt. This is simple, requires > no action on the part of the end user, I am not convinced about the second half of your proposal which was > BUT it might upset > any existing codes which already had -opt and -noopt > options. I think I could work around this so the existing > options took precedence, but it might still be slightly > confusing. I take it you are concerned about users who have worked around the present limitations of the command-line parsing of the PL_OPT_BOOL case by setting the the -noopt form of variable associated with the PL_OPT_BOOL option to True which would be a completely opposite result from what you propose above which would be to always set the -opt(-noopt) form of the variable associated with the PL_OPT_BOOL option to True(False). This is very similar to API breakage issues where the choices are to break the API or expand it (with the inevitable consequence of a sloppy, difficult-to-maintain API with most of the good names associated with deprecated API while strange variants of those names are used for the preferred API). <aside> My fairly strong feeling is it is always better to break to keep everything as simple and easy to maintain as possible. I realize that means there will be a small degree of breakage pain for our users for each of our releases rather than a huge breakage pain less often, but I feel that small but near-continuous breakage model is the better way to go. I am aware of at least one other project that uses that model (Octave), but now they have straightened out how they #define components of their release numbers in installed headers, it is fairly straightforward for others to test the Octave version components with the C++ preprocessor and thus deal with those changes. Ironically it turns out we have had even worse issues with specifying the PLplot version information in our installed headers, but I have just (revision 13048) fixed those so it should no longer be an issue for users to easily test the PLplot version information with the C preprocessor if so desired. </aside> In sum, I like the first half of your proposal above to change the meaning of PL_OPT_BOOL options. But I would simply make sure there was a good notice about that backwards-incompatible change in the release notes rather than doing anything extra as in the last half of your proposal. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
