[Bioperl-l] Bio::RootI

[Jason Eric Stajich]

Let's go with your changes Lincoln.  I think we need to evolve these
interfaces.  We've found things that 'work' but let's now go with the more
correct separation of data and interfaces.  Please implement away and let
us know where we need to start to make corrections.

I'd like to us to start to clean house in preparation of 1.0 and remove
some of the cruft in the Root dir.  We've talked about deleting some of
the unused objects there and I'ld to see reliance on the File::Spec and
File::Temp to implement functionality rather than our stand-in methods in
Root::IO.  This will widen the required modules list for bioperl but I
think both the aforementioned ones are part of 5.005 anyways (albeit with
less complete API as in 5.6 so have to be careful).

We are planning to only support perl >= 5.005 with the next 1.0 release.
I for one would love to not have to worry about dealing with all the
Filename separator and tempfile cleanup within bioperl but to delegate to
someone else's implementation so we can get down to the whole 'bio' part
of the project...

One caveat with tempfiles while my stream is going here - we have problems
with File::Temp in that it only cleans up files when the script exits NOT
when the object is DESTROYed s.t. people doing massive amounts of
processing which might produce tempfiles (running StandAloneBlast) without
exiting the script (mod_perl + standaloneblast) don't have their files
cleaned up.  We need to think about a strategy here as well as we had been
relying on the ability to do the cleanup in the DESTROY method (could
certainly implement this more nicely without assuming an underlying hash
as the data object than we did originally).

-jason
On Sun, 18 Nov 2001, Lincoln Stein wrote:

> The decoration functions, like throw(), would still be there.  I'm
> comfortable with interfaces implementing some useful functions.  It's
> the ones that depend on the hashref being there that I would turn into
> pure interface (stub) functions.
>
> Unless there is a big objection, I'll make the proposed changes.
>
> Lincoln
>
> Ewan Birney writes:
>  > On Sun, 18 Nov 2001, Elia Stupka wrote:
>  >
>  > > Hi Lincoln, Elia here,
>  > >
>  > > I think I can shed partial light on this:
>  > >
>  > > > I'm puzzled as to why the root interface has any object data at all.
>  > > > I've always thought that interfaces should have methods only, and no
>  > > > object data.
>  > >
>  > > Well, this is one of those things that you either hate or love... I
>  > > believe Ewan likes to call them *decorated interfaces*, the point being
>  > > that since perl allows you to put object data methods in an interface, you
>  > > might as well take advantage of it and put some of them in the interface.
>  > > This makes anybody coming straight from Java or C feel pure disgust, but
>  > > can be considered useful. In practice, as you suggest, the clean solution
>  > > is splitting it into an interface and a super class for shared methods,
>  > > which doesn't hurt anybody, and is a-la-proper-OO-language.
>  >
>  > I like "decoration" to be function only.
>  >
>  > I think what Lincoln doesn't like is the data/implementation dependence of
>  > the RootI assumming there is a hash there - I don't like this at all.
>  >
>  >
>  > Obviously all things are possible, and we just have to decide. I like the
>  > rule:
>  >
>  >
>  >   Interfaces only contain function stubs which throw or functions with
>  > implementation which only depend on other function stubs.
>  >
>  >
>  >   Bio::Root being a "default" implementation object with the IO smarts I
>  > think is a good idea.
>  >
>  >
>  >
>  >
>  >
>  > >
>  > > I suppose if we do it then we should at some point make an active
>  > > decision, whether we support decorated interfaces or not.
>  > >
>  > > Hope this explains it... ;)
>  > >
>  > > Elia
>  > >
>  > > --
>  > > ******************************
>  > > * http://www.ebi.ac.uk/~elia *
>  > > * tel:    +65 874 1467       *
>  > > * mobile: +65 90307613       *
>  > > * fax:    +65 777 0402       *
>  > > ******************************
>  > >
>  > >
>  > > _______________________________________________
>  > > Bioperl-l mailing list
>  > > Bioperl-l@bioperl.org
>  > > http://bioperl.org/mailman/listinfo/bioperl-l
>  > >
>  >
>  > -----------------------------------------------------------------
>  > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
>  > <birney@ebi.ac.uk>.
>  > -----------------------------------------------------------------
>
>

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