[Biojava-l] Nasty CompoundLocation `issue' -- incompatible change

[Thomas Down]

On Thu, May 31, 2001 at 02:02:54PM +0100, Thomas Down wrote:
> A warning about the public constructor on CompoundLocation:
> 
>    public CompoundLocation(List locs);
> 
> This is assuming that the list you passed in is already sorted
> into ascending order.  If not, getMin() and getMax() may
> return incorrect values!  I think this might have crept in
> during the post-bootcamp Location refactoring.  It won't
> affect /too/ many people since usually CompoundLocations
> get built using the union operator.  However, this is can
> be quite expensive for building big locations, so it's
> still useful to be able to construct a Location from
> a list of blocks.

Okay, I needed a quick fix for this one, so I've gone ahead
and checked something in.  We can still talk more about details
if there's demand.  However:

  - There's now an n-ary Location union operator:

      public static Location union(Collection locations);

    This is the preferred way to construct really complicated
    locations.  You can pass any old bag of locations in
    (don't have to be sorted, contiguous, or anything really...)
    and get a sensible answer out.  Obviously come JDK1.5, this
    will change to (Collection<Location> locs).  We can dream,
    anyway...

  - The constructor of CompoundLocation is now package private,
    because it was a /seriously/ dangerous method.  As well as
    the min/max problem I reported yesterday, it was also possible
    to pass in data which would break the blockIterator()
    contract :(.

There wasn't any code within biojava itself which got broken
by this change.  However, you may have code which was using
the CompoundLocation constructor (there were a few cases
in biojava-ensembl, which is where I found the problem).
Change this to use the new n-ary union operator.

Slightly longer term, I'd like to make the whole CompoundLocation
class package-private.  Since the only way we construct them now
is by union of other Locations, we might as well hide all the
gory details.  Does anyone have any problems with this?

   Thomas.