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

On 09/01/2017 10:01 AM, Chapman Flack wrote:
> On 09/01/2017 09:41 AM, Jean-Louis Martineau wrote:
> 
>> 'directory' is not a good name, so if you get a better name, we can use it.
> 
> Hmm, destination? workspace? ...? Does that mean you would consider
> changing it for all apps old and new in order to have it consistent?

Ok, if destination only makes sense for restores - how about
something like target? or object?

>> I'm not sure that all the declare_*_options are required as everything
>> 'backup' need must be accepted for all commands.
> 
> OK, I wasn't sure about that. There might still be extra 'restore'
> properties, right? Because you can set those in an amrecover session.

As I look at this more, I think the declare_*_options methods are
still ok. They all call declare_common_options to set up the common
ones, and the POD already recommends to put any new properties in
declare_common_options, exactly because all commands need to know
about them (with the possible exception of recover-time-only
properties).

So that leaves the only real differences between the other methods
being the fixed API-specified options that differ (only backup can
have --state-stream, only restore can have --dar, only estimate
can have --level more than once, etc.) and those differences are
real, yes?

Maybe the POD could be even more clear that most of these shouldn't
be overridden in an application, it should only override
declare_common_options and possibly declare_restore_options.

While some of the other methods could be made "private" so an
application /can't/ override them, I'm not sure that's worth
the effort. There's a slightly different syntax to call them,
so run() would then have to know which was which ... right now
it just looks up 'declare_'.$subcommand.'_options' and calls it;
I like simple. :)

-Chap