in reply to Re^2: Dynamic option
in thread Dynamic option
It is hard to give an answer without knowing your validation logic needs, whether or not -nc/-nd can themselves have values and so on. I use Perl 5.8.8 and 5.10.0. Given the features available to me, I'd do one of the following:
(a) No validation needed: I'd just define the whole lot (-nd, -na, -nc) as options. That way you can easily test for existence like you are doing in your sample code. Also you can easily assign values. Just because something is in the option list doesn't mean that the user has to enter it.
(b) Validation needed. There are a couple possibilities here. I'm still guessing at what you want though because I'm not sure of the meaning of the intial -input [-nd -na]. Are those defaults? Also I don't know which sub-sub-options (nd/na) can be applied to more than one sub-option(data/modem/app). Nor do I know if na/nd can have values of their own.
If I were to (a) want to set defaults for data/modem/app (b) distinguish between -nd for data vs. -nd for modem, I might do something like this:
- treat -data, -modem, -apps as separate options rather than values of -input
- make na, nc, nd values of -input, -data, etc.
- during the option validation phase, check data/modem/apps. If they don't have a value, assign them the default value specified by the input option. If the do, scan the values to make sure they are legal.
But I might do something entirely different if -na, -nc, -nd had values of their own. It just isn't possible to answer your question without knowing more. Command line options are data. Anything more complicated than a simple list needs to be understood and analyzed like a mini-data model. Structure of any data depends on its functional dependencies (how many values can an option have, what are its constraints, what are the interdependencies among options, and so on). The possibilities are quite broad which is why you aren't likely to find some out of the box solution except for the most simple cases.
When you've written up your more detailed explanation of your validation logic, I'd recommend, you update your original post with a what you wrote above plus the new validation information. I'd recommend you reply to your own original post with a comment rather than this one. (Anonymous monks can't edit their posts). I think that would be better than a reply to this comment. That way people can see your needs without having to burrow down into replies of replies. You are liable to get more on target answers that way.
In the future, also please consider posting questions as a named user. You can edit your posts that way. In general, the ideal solution when an initial post is unclear is to update the initial post, but that option isn't available to you as an anonymous poster.
Update - changed recommendation - anonymous monks can't update posts.