[Bioperl-l] deprecated modules

[Peter Kos]

Hi,

I see.
It sounds pretty reasonable.
Thanks for the detailed explanation.

Regards
Peter

On Monday, August 19, 2002 6:44 AM, Jason Stajich 
[SMTP:jason@cgt.mc.duke.edu] wrote:
> On Thu, 15 Aug 2002, Peter Kos wrote:
>
> > Hi,
> >
> > Bio::Tools::Blast has been deprecated for a while - but it still
> > works.
> >
> > I hope good old scripts will be easy to adjust to work with the
> > new
> > set of modules.
> >
> > What is the benefit from removing them? Will they cause problem
> > with
> > respect to the self-compatibility and homogeneity of the whole
> > toolset in later versions?
>
> Homogeneity, confusion, the toolkit is too scary for people as it
> is.
> When they are looking for a logical thing to do blast parsing they
> pick the first thing they see.  Then they find it hard to use or it
> doesn't work and they give up.
>
> I'm not a big fan of people reporting bugs in Tools::Blast and my
> first
> response being, don't use that module its not supported, etc..  Yet
> it
> happens all the time.
>
> > I would feel that it may be enough to state clearly that they are
> > deprecated so that new scripts should not use them. If these
> > modules
> > do not cause too much trouble for you, I would not mind wasting
> > that
> > much diskspace. Even now I store the whole Bioperl, although lots
> > of
> > the modules will never be necessary for me, and I am happy to
> > have
> > all of them under my fingertip, just in case.
>
> You can always get the old modules from previous releases or CVS. 
If
> you
> want to keep using Tools::Blast use an older version of the toolkit
> which
> contains it.  It can just be in your PERL5LIB or still installed.
>
> > There may be hundreds if not thousands of scripts using the
> > deprecated modules worldwide, and they may later cause problems
> > on
> > machines with only brand-new installations of Bioperl.
> >
>
> They can continue to use and install older version of bioperl if
> that is
> the need, but we have to move forward.  Keeping old unsupported
> modules in
> the toolkit is bad for users who are new to the system and pick up
> the
> most logically named module for their tool.  The original design of
> the
> toolkit was not perfect, nor is it perfect now.  It will continue 
to
> mold
> towards what people want to accomplish and support.  We needed a
> better
> pluggable and extensible system for parsing search reports that do
> not end
> up with redundancies.  Hence SearchIO.  I do not want to support > 
1
> blast
> parser in Bioperl without good reason.
>
> I feel uncomfortable releasing code with a module which I KNOW
> doesn't
> work for certain cases (this is in no way a slight towards SteveC,
> but the
> data providers, compute providers, formats, etc change).  So it has
> been
> deprecated.  It doesn't conform to a lot of the newer inheritance
> and it
> is very difficult for people to get in and read.
>
> > I also understand that redundancy may lead to confusion, but
> > TIMTOWTDI, as the Camel says.
>
> Not when you are trying to release a software pkg that is stable
> and
> extensible.  There should be a set of consistent rules that
> developers
> working in concert should try and follow so that an outside 
observer
> can
> follow those rules and understand how the pkg is organized.  This 
is
> an
> unrealized dream of course, but something we need to strive for.
>
> There in fact should be a lot of consistency in the pkg otherwise
> people
> are totally lost and modules are not easily extended.
>
> We have to be pretty explicit and disciplined if we want to manage
> reasonable OO out of Perl so TIMTOWTDI is not always a good mantra
> when
> you want to design reusable modules for an audience that may not be
> perl
> saavy.
>
> -jason
> > ..........
> > Peter B. Kos
> > (RITE)
> > kos@rite.or.jp
> >
>
> --
> Jason Stajich
> Duke University
> jason at cgt.mc.duke.edu
>
.........................
Peter B. Kos
(RITE)
kos@rite.or.jp