[Bioperl-l] For CVS developers - potential pitfallwith"returnundef"

[Chris Fields]

> -----Original Message-----
> From: Lincoln Stein [mailto:lstein at cshl.edu]
> Sent: Wednesday, May 31, 2006 4:07 PM
> To: Chris Fields
> Cc: 'Hilmar Lapp'; bioperl-l at lists.open-bio.org; 'Heikki Lehvaslaiho'
> Subject: Re: [Bioperl-l] For CVS developers - potential
> pitfallwith"returnundef"
> 
> 
> > Instances: 17	Module : Bio::DB::SeqFeature::Store
> 
> This is intentional. Bio::DB::SeqFeature::Store is intended to be a
> virtual
> base class. The throw_not_implemented() calls are there to force
> developers
> to override the needed interface methods.
> 
> If this is not the right way to do it, let me know and I'll fix it.

That's the right way, though I don't really know what the 'right way' is.
Sorry Lincoln, didn't mean to imply anything directly at you specifically; I
responded to your last post to stay in the thread, so to speak.  It was
meant to be a general statement that some classes haven't implemented
methods specified by their abstract base or interface class.  This is just
output from a quickie script I wrote up to check on this and see how many of
these statements are out there, and since there isn't a full-proof method to
know what an abstract base class is, it pulls in a few abstract classes
(such as yours) along with all the others.  At least there aren't as many
hits as Torsten's ~400-500 for 'return undef'! 

Anyway, I'm not sure what would be the best place to address code problems
or issues like the unimplemented methods issue or Torsten's audits (list,
wiki, etc); it's a delicate issue b/c it's bordering on code critiquing and
what constitutes good vs. bad code.  I remember some pretty heated arguments
about the 'proper' way to do things a while back involving AUTOLOAD'ing
methods, which I think is summarized somewhere in the wiki.  Myself, I'm a
microbiologist and not a programmer, so I'm prone to bouts of hackery, but I
try to have the code at least do what the docs state.

Chris

> Lincoln
> 
> 
> > Instances: 2	Module : Bio::DB::SeqVersion
> > Instances: 3	Module : Bio::DB::Taxonomy
> > Instances: 1	Module : Bio::FeatureIO::bed
> > Instances: 1	Module : Bio::Map::Marker
> > Instances: 1	Module : Bio::MapIO::fpc
> > Instances: 1	Module : Bio::MapIO::mapmaker
> > Instances: 1	Module : Bio::Restriction::IO::bairoch
> > Instances: 1	Module : Bio::Restriction::IO::itype2
> > Instances: 1	Module : Bio::Restriction::IO::withrefm
> > Instances: 1	Module : Bio::Tools::Analysis::SimpleAnalysisBase
> > Instances: 3	Module : Bio::Tools::Run::WrapperBase
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: bioperl-l-bounces at lists.open-bio.org [mailto:bioperl-l-
> > > bounces at lists.open-bio.org] On Behalf Of Lincoln Stein
> > > Sent: Wednesday, May 31, 2006 1:15 PM
> > > To: Hilmar Lapp
> > > Cc: bioperl-l at lists.open-bio.org; Heikki Lehvaslaiho
> > > Subject: Re: [Bioperl-l] For CVS developers - potential
> > > pitfallwith"returnundef"
> > >
> > > If the documentation says "returns false" then I expect to be able to
> do
> > > this:
> > >
> > > 	@result = foo();
> > > 	die "foo() failed" unless @result;
> > >
> > > If the documentation says "returns undef" then I expect this:
> > >
> > > 	@result = foo();
> > > 	die "foo() failed" unless $result[0];
> > >
> > > Lincoln
> > >
> > > On Wednesday 31 May 2006 14:08, Hilmar Lapp wrote:
> > > > On May 31, 2006, at 12:03 PM, Lincoln Stein wrote:
> > > > > If the subroutine is documented to return "false" on failure, then
> > > > > one must call
> > > > > return (or "return ()" ).
> > > >
> > > > The problem seems to be that 'a value that evaluates to either true
> > > > or false' and 'a [meaningful] value or undef' and 'a value or
> > > > false' ('a value or no value) are not the same in perl. And what
> > > > would/should one expect if the doc states 'true on success and false
> > > > otherwise'?
> > > >
> > > > Maybe the documentation should also be fixed to avoid any ambiguity.
> > > > I.e., avoid documenting 'a value or false' because it may be
> > > > ambiguous (not only) to the less proficient. 'True or false' should
> > > > imply a value being returned.
> > > >
> > > > Comments?
> > > >
> > > > 	-hilmar
> > >
> > > --
> > > Lincoln D. Stein
> > > Cold Spring Harbor Laboratory
> > > 1 Bungtown Road
> > > Cold Spring Harbor, NY 11724
> > > (516) 367-8380 (voice)
> > > (516) 367-8389 (fax)
> > > FOR URGENT MESSAGES & SCHEDULING,
> > > PLEASE CONTACT MY ASSISTANT,
> > > SANDRA MICHELSEN, AT michelse at cshl.edu
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l at lists.open-bio.org
> > > http://lists.open-bio.org/mailman/listinfo/bioperl-l
> 
> --
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
> (516) 367-8380 (voice)
> (516) 367-8389 (fax)
> FOR URGENT MESSAGES & SCHEDULING,
> PLEASE CONTACT MY ASSISTANT,
> SANDRA MICHELSEN, AT michelse at cshl.edu