Bug #61438 for Getopt-Euclid: Need the possibility of distinguishing between option not used or used without optional argument - added field 'no_val'

Is anybody alive? I've provided a fix to a design shortcoming that was indispensable for me (and, I guess others), with the understanding that this would be soon implemented in the new release of this module. Since we agreed on the interface, I went ahead adopting my implementation while waiting for the official release. Over eight months have passed without any progress. Some time ago I've learned from Kevin that he has handed everything to somebody else supposedly more active with bug-fixing and code improvements. However, the page shows Kevin still as the curator and no mention of the new person: What is going on? Paolo On Fri Sep 17 17:36:32 2010, pamedeo wrote: Show quoted text

Hi Paolo, My time being limited, I appreciate that you submitted a patched version of Getopt::Euclid. I am afraid that Kevin never got the time to properly finish what he was up to with Getopt::Euclid and that's why your patch never made it in the codebase so far. Note that Kevin set up a Git repository for Getopt::Euclid (see http://sourceforge.net/scm/?type=git&group_id=259291), so for any future hacking of Getopt::Euclid, use this git repository and it will make our life easier. Also, there is a series of tests (in the ./t/ folder) that Getopt::Euclid uses to limit the risk of bugs. So, ideally, when you submit code, you should submit new tests and make sure that the old tests still pass successfully. Now, regarding this option that you suggest... To be honest, I am not sure that I like it the way it is because there is never the need to have both a "strong" default like log_level.default: 'NOT SET' and a "weak" default like log_level.no_val: 'DEBUG' at the same time. But how about keeping the general idea but specifying the following way? =item [-]-debug [<log_level>] Debug: optional log level. If no log level is specified, it is assumed to be 'DEBUG' =for Euclid: log_level.type: string log_level.default: 'DEBUG' log_level.default.is_strong: 0 And, of course, the default would be to have strong default, i.e. log_level.default.is_strong of 1, to keep the compatibility with previous versions of Getopt::Euclid. Florent

Thanks, Florent for the quick reply. Honestly, I'm a bit confused, since I haven't found anywhere in the documentation and current release anything about 'is_strong' modifier. What would it do? Would it undef the variable associated with the option in the case the option is not used? What I need is to distinguish between not using an option and using without the optional argument (e.g. --verbose writing to STDOUT if no argument is used or writing to a file whose name is provided as argument: definitely you want the program to shut up if you don't use --verbose). At the same time, it is necessary to respect the backward compatibility (i.e. the option with optional argument set to the default value both when it is not used or when it is used without arguments--useless behavior, in my opinion), we need not to alter any behavior of the existing fields. I have achieved that by introducing the 'no_val' field. I thought that the meaning would be intuitive, and--definitely--the implementation in the code is quite easy. As matter of fact am using it successfully in our code and have never encountered any issue with any other script using Getopt::Euclid. Unfortunately, I do have a full-time job and am quite busy on the side as well. I'm not interested in any way to become one of the developers of this module. I thought that providing an implementation of the possible solution in a way that could be easily "diffed" with the latest development draft (I believe that I've introduced changes in maximum ten lines of code) would be a good step forward compared to just whining about a bug. Since the solution to our problems has been already implemented internally, I have serious doubt that my boss would authorize me spending more efforts and resources for this module. If I have to do it in my "free time", I'll probably could think messing with the Git repository and working on some test, but it will take much longer. Thanks! Paolo On Wed Aug 31 00:52:06 2011, FANGLY wrote: Show quoted text

Thanks, Florent! I appreciate it, and I'll stay tuned. Paolo