Re^2: deriving usage from Getopts::Long

What you describe is easily done with Getopt::Declare. I haven't had the multiple module situation, so I haven't had to use an "accept parameter" function, but that could easily be done.

The parameter description is just a string passed to G::D. The string can be built up piecemeal by modules as they load (or perhaps each module adds a key to a hash, and after all modules are loaded, the hash is processed into a string).

The code callbacks are called "actions" in the G::D documentation. Parameter checking syntax, either by fundamental type (e.g., integer), regex, or code block, is already provided.

Perhaps I should develop a helper module for G::D to do what you suggest?

-QM
--
Quantum Mechanics: The dreams stuff is made of

Comment on Re^2: deriving usage from Getopts::Long

Replies are listed 'Best First'.
Re^3: deriving usage from Getopts::Long by Tanktalus (Canon) on Jul 30, 2005 at 15:05 UTC
I actually doubt it would be that easy to do with Getopt::Declare. The reason is that the actions are done in the caller's namespace - and G::D is not going to know which namespace is which. Worse, it looks like these actions will affect only package variables. They aren't proper closures, and I need closures to affect the proper private variables. I'm sure it could still be faked somehow, but it would not be the straight-forward method you may think it is. Besides, once you have a wrapper, it really doesn't matter which one it wraps, as long as the caller(s) don't need to change. ;-) (Also, it's imperative for my app, anyway, that all parms are parsed in a certain order, irrespective of the order on the commandline, which is also contrary to G::D's method. So my wrapper just gets G::L to parse the whole thing, and then we validate in order.)	[reply]

Replies are listed 'Best First'.

Re^3: deriving usage from Getopts::Long
by Tanktalus (Canon) on Jul 30, 2005 at 15:05 UTC

I actually doubt it would be that easy to do with Getopt::Declare. The reason is that the actions are done in the caller's namespace - and G::D is not going to know which namespace is which. Worse, it looks like these actions will affect only package variables. They aren't proper closures, and I need closures to affect the proper private variables. I'm sure it could still be faked somehow, but it would not be the straight-forward method you may think it is.

Besides, once you have a wrapper, it really doesn't matter which one it wraps, as long as the caller(s) don't need to change. ;-)

(Also, it's imperative for my app, anyway, that all parms are parsed in a certain order, irrespective of the order on the commandline, which is also contrary to G::D's method. So my wrapper just gets G::L to parse the whole thing, and then we validate in order.)

[reply]