Perhaps good administration would be to introduce a generic Deprecated::
namespace. Module authors can move their own old modules there if they
want, and there can be Deprecated::P5 for stuff like dbmopen,
Deprecated::Perl5 could export everything it has to Deprecated, with a
symbol group ("tag"), so you can
use Deprecated :perl5;
use Deprecated :all;
And Perl can have built-in warnings, as one huge refactoring of all
those warnings you'd otherwise have. The 'deprecated' category should
warn for use of any symbol in Deprecated::.
use warnings :deprecated;
no warnings :deprecated;
(Explicit 'use Deprecated' would export symbols, and because then the
symbols are used from ::, no warning is emited.)
On Sat, 2005-03-26 at 12:05 +1100, Andrew Savige wrote:
> Please note that I am not an expert on any of this, I was just
> wondering whether we are going to clean up the old p5 library
> interfaces as part of the move to p6. Or must we support the
> old p5 library interfaces for backwards compatibility?
No. Please, no. :)
As I see it, Perl 6 has a chance to start over with a very small set of
core libraries -- perhaps embarrassingly small -- so as not to entomb
our current, potentially-blepharitic guesses at good Perl 6 design
principles for the next twenty years or so.
If people really want File::Find or MakeMaker interface compatibility in
Perl 6, I suggest a new top-level namespace, namely
GodHelpYou::File::Find, though P5Compat may be less exciting and more
Maybe I'm just being dense, but I don't see any particular reason to
make it easy to use deprecated features en masse. If they want a Ponie,
they want a whole Ponie, and not large chunks of a Ponie.