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

[Carnë Draug]

On 3 February 2013 21:54, Fields, Christopher J <cjfields at illinois.edu> wrote:
> 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.

Should passing the tests be enough? There's one for TCofee. At the
moment I don't see how this would cause compatibility issues, we are
adding an option, not removing it. But the comment on the code,
stating plainly that the -param API was not wanted caught me by
surpise and why I'm asking.

> 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.

>From a quick glance at the list of TCoffee parameters I don't at the
moment see any that should cause problem.

I have submitted a bug report[1] which mentions some other issues I
found with TCoffee. If someone could comment on them would be great
and I can start fixing it.

Carnë

[1] https://redmine.open-bio.org/issues/3406