[Bioperl-l] TCofee does not accept named arguments and issue with output option

[Fields, Christopher J]

Carnë,

On Feb 2, 2013, at 7:44 PM, Carnë Draug <carandraug+dev at gmail.com> wrote:

> Hi
> 
> the TCoffee module does not options of the named argument type:
> 
> -arg => option
> 
> one needs to do like
> 
> 'arg' => option
> 
> Is there a special reason for this? I tracked down this to the commit
> 
> 7b2f9189fe2af4f99f1c3d7fe79c732bfe01261e
> 
> 12 years ago[1]. A comment on the code actually says "don't want named
> parameters"[2] (though the commit message sounds pretty innocuous
> "migrated to new Bio::Root::RootI chained new"). Is there a reason for
> this? The rest of bioperl has no issue with named parameters, and the
> API should be the same as Clustalw which also has no problem with it.
> This is very easy to fix, I can submit a pull request no problem.

IIRC the reasoning behind this was to differentiate Bioperl parameters from command-specific ones.  This decision predates my involvement w/ core dev, but my general feeling is that anything that is an object attribute (regardless whether it is a direct representation of a value passed to a wrapped program or not) should be preceded by '-' for consistency.  

The downside of big changes like this: potential backwards compatibility issues.  Such changes would need to be tested out rigorously, as there are a ton of old scripts that would potentially break with a direct change.  I don't have a problem breaking this with a bioperl 2.0 release, though.  

> Also, shouldn't the code complain in the case of non-supported
> options? Took me a very long time to find out the problem because
> there was no complaints coming from the code.

Yes, it should complain when options are given that do not make sense, some validation would help there.  With some modules this might be a side-effect of using AUTOLOAD or simply not checking the parameters.

> There is also a problem with the way it handles the output option.
> I'll have to look closer into it, but the documentation is simply
> incorrect. "'output' => 'fasta_aln'" gives an error while just 'fasta'
> (undocumented), works fine.

That's entirely possible.

> Carnë
> [1] https://github.com/carandraug/bioperl-run/commit/7b2f9189fe2af4f99f1c3d7fe79c732bfe01261e
> [2] https://github.com/carandraug/bioperl-run/commit/7b2f9189fe2af4f99f1c3d7fe79c732bfe01261e#L0R374

As an aside, there are a few downsides of trying to implement command-line parameters as perl object attributes (getter/setter), one being that many can't be directly represented as an object attribute (namely, anything that can't be a getter/setter named subroutine, such as those having hyphens, starting with a number, etc) so you have to hack your way around it.  Infernal was this way IIRC.  Maybe these should just be simply stored as a semi-validated set of key-value pairs.  

chris