As the initial proponent of the opposing RFC, I feel I should make a
response. Let the will of the Perl6 community and Larry Wall prevail.
I'm sure we'll all be mostly happy, no matter where that takes us.
Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> Perl5 is usable with no hassle as a quick-and-dirty problem-solver by default.
> It is ideal for one-liners, short scripts, and quick hacks that have no need
> for extra protection or error-checking. It is also great for large projects
> by making use of the C<warnings> and C<strict> pragmas.
Well, there's a really diverse community, here. Many of us use Perl
almost exclusively as a command-line utility. In my work, we use Perl
as a primary programming language and expect a lot of things that make
more sense for larger, more permanent programs.
If your scripts are one-liners that involve the -e switch and we go
with "strict 'vars' in all cases except -e," then you have no need to
worry; the proposed changes will not affect you. If your scripts are
slightly larger, then part of the Perl5 -> Perl6 translation process
should cover this for you. We'll keep hashing this out to try to
satisfy everyone, so keep talking.
> In large projects which require the constraining pragmas, it is not an issue
> to take the extra steps and 'use' them.
How many of those large projects have you participated in? How many
people do you work with that you have to constantly cajole and prod to
"use strict;"? It is indeed an issue, in several ways.
What if the default strictness of vars was a compile-time option to
be decided by the administrator of each site?
> This RFC is particularly concerned with the idea of having C<strict 'vars'> on
> by default. This is an attempt to get around Perl's design of having all
> variables global by default, and lexical only when declared.
Some would say that Perl wasn't exactly designed aroung all global
variables; it was more of an accident. In fact, the Camel book 2 all
but says so.
J. David
