Re: Streamlined application/script development [Re: coding an Application in perl]

Chapman Flack <[email protected]> Mon, 11 Sep 2017 12:00:57 -0400
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <[email protected]>
On 09/11/2017 11:25 AM, Jean-Louis Martineau wrote:

> Do the convention for code reference and 'opt_' prefix is required? Is
> it used? Can you give an example on how to use it?

I did create that convention. If you put an array or a hash into
$refoptspecs->{'foo'}, then they collect the values of --foo in a
typical way.

However, if you put a code reference there, it should check the
value, and then store it in $refoptspecs->{'opt_foo'}.

new() knows this convention, and when it is building
$self->{'options'}->{'foo'}, it uses the values for --foo
from $refoptspecs->{'foo'} unless that is a code reference,
and in that case it uses the values from $refoptspecs->{'opt_foo'}.

So the application doesn't need to worry about the convention
much; by the time new() is done, the values for every option --foo
are in $self->{'options'}->{'foo'} just as you would expect.
The main thing is (because of the convention) an application should
not invent any real options named opt_something.

If an application implements a custom option-checking sub, it needs
to know the convention (the checking sub stores its result at
->{'opt_foo'}). But that's about it.

The one (so far) existing example in the code is
boolean_property_setter in Abstract.pm.  One example of code
using it is amgrowingzip. It just sets $refoptspecs->{'flock'}
to be boolean_property_setter, then later in the code it can
simply use $self->{'options'}->{'flock'} as a boolean. It never
needs to care whether the server sent 1, y, YES, TrUe, or oN, etc.

-Chap