develooper Front page | perl.perl5.porters | Postings from March 2000

Re: A plea for more pollution

Thread Previous | Thread Next
From:
Raphael Manfredi
Date:
March 16, 2000 09:08
Subject:
Re: A plea for more pollution
Message ID:
15260.953226609@lod23.gnb.st.com
Quoting mjtg@cus.cam.ac.uk:
:"Simon Cozens" <simon@othersideofthe.earth.li> wrote
:> FAILED:
:>	Storable (sv_yes, sv_no, sv_undef undefined)
:> 	Curses (na)
:> 	Term::ReadLine::Gnu (na, sv_undef)
:
:Lack of pollution strikes again.    We're going to see a lot of these.
:Lots and lots and lots and lots, clogging up perlbug and c.l.p.* .

I don't understand this for Storable.

I thought Storable was behaving nicely with the 5.6 branch.
I even recently added the

	#include <patchlevel.h>

explicitely in Storable-0.6.9 to cope with future 5.6, as I've been told
by someone.

Nowadays I stick with stable Perl versions and only support Storable for the
latest Perl version, because I lack the tuits to do otherwise. This means
that Storable *might* no longer compile with 5.005 once 5.6 is out, because
I'll fix it to work with 5.6, which might break 5.005...

I can't force people to upgrade to the latest perl version, yet I cannot
maintain Storable endlessly to be backward compatible. The current Storable
does not compile with 5.004, and I don't know how to fix that, because the
people complaining lack the skills to fix it themselves and send me
the patches, and, frankly, I lack the time/motivation to do it.

One alternative would be to include Storable in the core, which would mean
no incompatibility problems like those: since many modules depend on
Storable working, and due to its sensitivity to Perl internals, I've come
to the conclusion that it's the only sensible choice in the long term.

Despite being close to the 5.6 release, I ask you that you consider it.

Raphael

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About