[Bioperl-l] est2genome

Graham McVicker mcvicker@ebi.ac.uk
Sat, 12 Oct 2002 22:50:05 +0100 (BST)


On Sat, 12 Oct 2002, Ewan Birney wrote:

> 
> 
> >
> > >
> > > Also, in a final note, Ensembl is starting to standardize their
> > > function
> > > names from each_XX to get_all_XX
> >
> > Excellent - that's very similar to how we're moving, right? The
> > difference is that we have get_XXXXs which returns an array, and
> > get_all_XXXXs, which returns a possibly flattened array (e.g., for
> > SeqI this would be get_SeqFeatures() instead of top_SeqFeatures(),
> > and get_all_SeqFeatures() instead of all_SeqFeatures().
> >
> > Ewan what's the plan for this distinction in Ensembl?
> 
> I am not the person with the definitive answer - I have cc'd in Arne and
> Graham who do have the definitive answer - my reading of it is that we
> have the following conventions:
> 
> 
>   get_all_XXXXX = returns a list of XXXX
>
>   get_XXXXX = returns a single scalar of XXXX
> 
>   fetch_XXXX_by_YYYYY = is a database adaptor specific convention,
> returning one XXXX by criteria YYYY
> 
>   fetch_all_XXXX_by_YYYYY = ditto except it is a list
> 
>   list_all_XXXX = returns a a list of scalar which are not objects (eg,
> ids etc)
> 
>

Yes. That is pretty much the standard we have been using.  Couple of notes
though:
We don't actually use:
  fetch_XXXX_by_YYYYY
rather we use: 
  fetch_by_YYYYY
since the type of object being returned by the adaptor is always
consistent.  E.g. GeneAdaptor fetch_by_YYYY methods return Gene objects
and only Gene objects.

The conventions
  fetch_all_XXX_by_YYYYY
and 
  list_all_XXXX 
have not actually been put into practice yet.  We have discussed this, and
decided that it would be good to distinguish whether a list or scalar
whould be returned via the method naming.  We also decided that an
all-or-none approach was best since a sometimes-implemented convention
would be worse than no convention at all.  We will probably decide over
the next week what to do and possibly put the new namings into effect
before the November release.


An additional idea we were considering is the use of list references as
arguments and return values instead of lists.  List references are more
efficient to pass around, and allow for a bit more flexibility (i.e. you
can pass multiple listrefs, or return multiple listrefs).

The downside of the listref approach is that they are more confusing to
use for inexperienced programmers, and would require a lot of changes to
the code to put into place.  Wherever possible we have also tried to chain
phased out ensembl methods to the new method versions (with a warning),
however, the switch to listrefs would also complicate this approach since
even methods that were not renamed would return different types.  As long
as we rename methods instead of changing return values of old ones then we
could probably get away with this, but my current opinion is that listrefs
are more trouble than they are worth.
 
> 
> Is this right guys?
> 
> 
> 
> >
> > 	-hilmar
> > --
> > -------------------------------------------------------------
> > Hilmar Lapp                            email: lapp at gnf.org
> > GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> > -------------------------------------------------------------
> >
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
> 
> 

----------------------------------------
Graham McVicker
EMBL - European Bioinformatics Institute
Cambridge CB10 1SD, UK
Tel: +44 (0)1223-492584
Fax: +44 (0)1223-494468
----------------------------------------