Nathan S. Haigh
n.haigh at sheffield.ac.uk
Fri Jul 6 11:43:41 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Heikki Lehvaslaiho wrote:
> Hi Nat,
> These modules have not been touched for a while and were developed for a
> specific task. A revire is defiitely in order.
> The way RNAChange->label was written, it should return 'inframe' when given no
> alleles, but 'no change' would actually be better.
Wouldn't this effectively be changing the API since past scripts "could"
expect "inframe" to be returned.
> The multiple alleles were originally though to be a good idea, but the
> vocabulary for labels was developed for single allele, only, The use of the
> module ended up being limited to single allele, so add_allele() behaviour was
> conveniently ignored but not removed. :(
So add_Allele() and each_Allele() should be deprecated in favour of
- From my post about API's.....how should the capitalisation of
add_Allele() and each_Allele() be changed?
> On Friday 06 July 2007 14:54:33 Nathan S. Haigh wrote:
>> Nathan S. Haigh wrote:
>>> I'm taking a look at the tests for Bio::Variation::RNAChange.
>>> If you create a new oject without arguments:
>>> my $obj = Bio::Variation::RNAChange->new();
>>> What do you expect the following to return:
>>> I thought it would probably be:
>>> However you get:
>>> 'inframe, deletion'
>>> Can anyone in the know explain what behaviour would be expected?
>> Following on from this, AAChange has the following two methods:
>> add_Allele() and allele_mut()
>> It appears that allele_mut is only capable of remembering 1 allele at a
>> time, whereas add_Allele() is provided to add support for mutliple
>> alleles - is that correct?
>> However, add_Allele() also calls allele_mut(), such that mutliple calls
>> to add_Allele will result in the overwriting of the allele being
>> remembered by allele_mut(). Things are further complicated by the fact
>> that label() uses allele_mut() to decide on the label to return.
>> Shouldn't label know aout multiple alleles set by multiple calls to
>> It may be my lack of understanding alleles and what these classes are
>> intending to do, but trying to rewrite the test scripts to improve code
>> coverage has let me a little confused!
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Bioperl-l