[Bioperl-l] Bio::Range and Bio::Range

[Hilmar Lapp]

Heikki Lehvaslaiho wrote:
> 
> I'd like to update Bio::RangeI and Bio::Range before  branching to
> 0.7.
> OK Hilmar?
> 

It is, but see below.

> I already talked to Matthew Pocock who wrote them in the first place
> and I'll take the responsibility on caring for them from here on.
> 
> Bio::Range will be useful for the up-coming Marker classes.
> 
> What I am planning to do:
> 
> 1. Bio::Range throws an error if both start and end attributes are not
> set in the constructor. Move to more relaxed bioperl style that allows
> the creation of an object and then setting the attributes one by one.
> 

Good idea. Also more consistent with SeqFeature::Generic, which
implements RangeI, too.

> 2. Check that values for start and end are integers (positive or
> negative). Negative values sets this class apart from Bio::LocationI
> compliant classes that store locations on real sequences, i.e. >0
> only.
> 
>         Jason, is this correct? Bio::Location::Simple does not
>         enforce positive integers and returns '0' when
>         undefined. Shouldn't the return value be 'undef'?
> 

We discussed this already, I'd rather prefer undef, too. If you
define valid values as positive integers, however, 0 is as good an
indication of no valid values as undef.

> 
> 4. Rename union and intersection to _union and _intersection in
> Bio::RangeI. They return an array of three values. Instantiable
> classes like Bio::Range should recreate union and intersection and
> return a new object created from the array values. (->overlap_extent
> is kept as it is.)
> 
> Shout if you object or these plans threaten to break something.
> 

Indeed. You're suggesting to change an interface in a not
backward-compatible way. In BioPerl the likelihood that this is a
problem for any code outside of BioPerl is not high since most
people don't implement interfaces themselves.

Apart from that, the question is whether we want to require
implementing classes to provide these methods. If yes, they should
definitely be present in the interface. Methods with an underscore
(i.e., methods that are not part of the public API) do not make
much sense in an interface IMHO. If you think they're not defined
properly, you can change the definition.

	Hilmar

-- 
-----------------------------------------------------------------
Hilmar Lapp                                email: hlapp@gmx.net
GNF, San Diego, Ca. 92122                  phone: +1 858 812 1757
-----------------------------------------------------------------