Front page | perl.perl5.porters |
Postings from June 2010
On Wed, Jun 2, 2010 at 15:43, Jesse Vincent <jesse@fsck.com> wrote:
> On Wed, Jun 02, 2010 at 02:03:26PM +0000, ?var Arnfj?r? Bjarmason wrote:
>> >
>> > Basically, it comes down to, "if it global, you can't have it anyway".
>>
>> Right, but if it's reserved by perl, perhaps we should warn and
>> eventually prohibit uses of these constructs. As-is you can define and
>> use a sub called *, even though it's reserved.
>
> This would make me very unhappy. As an earlier commenter suggested, this
> is a great place for a Perlcritic policy, not for a blanket prohibition.
I think I shouldn't have thrown the d-word around. It tends to provoke
knee-jerk reactions.
What I'd like in a perfect world is for there to be a 1:1 correlation
between what our documentation claims, and what some optional warnings
category emits. Then I can turn it on and proceed to make my code
better, because I'll never be able to keep all the POD in my head at
one time.
I'd like to be able to turn on warnings for C<my $x if 0> because our
docs say it's undefined, and I'd like C<sub _ {}> to warn because I've
forgotten some pod section that explains how subroutines matching
/^[\W_]$/ have special scoping semantics, and that they're reserved
for Perl core.
I don't care if I have to do that with C<use warnings 'yes really all
warnings please'>. Or if code that doesn't request that warnings
category continues to work until Perl 5.* stops being released at all.
Would those sort of warnings be unreasonable for core inclusion? I
don't think perlcritic is a good place to put it, because in these
cases the core is claiming that something is undefined/reserved. So
it's different from "you used the wrong indentation style", which is
the sort of thing I think perlcritic should be used for.
Thread Previous
|
Thread Next