Re: [Fwd: Re: Moving the p5 standard library to p6]

1 view
Skip to first unread message

Juerd

unread,
Mar 26, 2005, 5:31:07 AM3/26/05
to perl6-l...@perl.org
chromatic skribis 2005-03-26 2:13 (-0800):
> 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
> appropriate.

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::File::Find.

Deprecated::Perl5 could export everything it has to Deprecated, with a
symbol group ("tag"), so you can

use Deprecated :perl5;

and even

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.)


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Chromatic

unread,
Mar 26, 2005, 5:13:03 AM3/26/05
to p6l
Forwarded...

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
appropriate.

-- c

Larry Wall

unread,
Mar 26, 2005, 7:42:45 PM3/26/05
to perl6-l...@perl.org
On Sat, Mar 26, 2005 at 11:31:07AM +0100, Juerd wrote:
: 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::File::Find.
:
: Deprecated::Perl5 could export everything it has to Deprecated, with a
: symbol group ("tag"), so you can
:
: use Deprecated :perl5;
:
: and even
:
: 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.)

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.

Larry

Reply all
Reply to author
Forward
0 new messages