[Bioperl-l] SeqIO parsing

Jason Stajich jason@cgt.mc.duke.edu
Wed, 25 Sep 2002 09:00:39 -0400 (EDT)


No more new root type classes unless absolutely necessary

Bio::Root::Root for objects
Bio::Root::RootI for interfaces

Bio::Root::IO for input/output abstraction

I'd like to see Bio::Root::NetIO for abstraction of network I/O one day
to aggregate LWP/Lincoln's raw socket access implementations.

Ewan and I have pretty much been against using AUTOLOAD in the general
case - so not without really good reason and not in the toplevel objects.

My opinions here anyways.

-jason

On Wed, 25 Sep 2002, Matthew Pocock wrote:

> Hi,
>
> If the abstract method exceptions where thrown by AUTOLOAD instead of
> method stubs then you could put the interfaces anywhere in the list. You
> could register the names of the abstract methods in a package-scoped
> variable (@ISA for inheritance, @METHODS for abstract methods?) which
> would at least give you easily accessible meta-data about what should be
> available - relatively easy to have an Interface.pm that does things
> like ensure that implementation packages do implement the interfaces
> they state they do.
>
> Or, how about starting foo.t with:
>
> use Foo;
> use Interface;
> Interface->validate("Foo");
>
> The body of validate can walk the @ISA tree finding <Bar>I entries, and
> call Foo->can for each method defined in BarI - if Foo->can($baz) ==
> BarI->can($baz) then the method is not overridden.
>
> It depends when/where you want the abstract methods to be checked for -
> test time or run time.
>
> If there is interest, I can knock up simple Interface.pm pod that
> flesshes this out.
>
> Matthew
>
> Hilmar Lapp wrote:
> >
> > On Tuesday, September 24, 2002, at 02:57 PM, Ewan Birney wrote:
> >
> >> On Tue, 24 Sep 2002, Hilmar Lapp wrote:
> >>
> >>> but always throw no matter what. Which is OK I think.
> >>>
> >>> Likewise, warn() only warns, and does not die.
> >>
> >>
> >> Except that the whole point of warn is that you can set it at a
> >> per-object
> >> level to throw or to stack trace etc via verbosity.
> >>
> >>
> >> In fact, that's the whole point of $obj->verbose(1);
> >>
> >>
> >> I know Jason likes this, so it is worth doing....
> >
> >
> > sure - no question - my point was different: what if you hit a call to
> > throw()/warn() and friends in an interface, not in an implementation.
> > Then I say you have to live with the fact that verbose() is not
> > honoured, which my point was should be fine. This means, you wouldn't
> > need verbose() implemented in RootI (or implemented such that throw()
> > always throws, and warn always warns, which is what a return of 0 would do.
> >
> > Conversely, if you throw() in an implementation inheriting from Root.pm,
> > then you can influence by calling verbose(...).
> >
> > Am I confusing or missing something?
> >
> >     -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
> >
>
>
>

-- 
Jason Stajich
Duke University
jason at cgt.mc.duke.edu