Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 72660
Status: open
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: dariusjokilehto [...] yahoo.co.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Exclude pragmas from Modules::RequireExplicitPackage
Date: Wed, 23 Nov 2011 12:28:25 +0000 (GMT)
To: "bug-Perl-Critic [...] rt.cpan.org" <bug-Perl-Critic [...] rt.cpan.org>
From: Darius Jokilehto <dariusjokilehto [...] yahoo.co.uk>
Download (untitled) / with headers
text/plain 623b
Hello, At work we run Perl::Critic as part of our test suite, and we have recently come across an issue with Modules::RequireExplicitPackage clashing with a new version of DBIx::Class::Schema::Loader, which we use to create our DBIC schema definitions. As of version 0.07011 DBIC::SL adds a 'use utf8' pragma before the package declaration for the files it creates. As pragmas are file-scoped unless they're in curlies I would suggest excluding pragmas from the rule. I'm attaching a patch - it's created from gitpan (v1.105 of Perl::Critic), please review and let me know if I need to make any changes. Thanks, Darius

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Wed, 23 Nov 2011 11:11:37 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 132b
I would prefer that the change be a list of exempt modules. I don't like the idea of having a whole class of modules being exempt.
Download (untitled) / with headers
text/plain 2.4k
On Wed Nov 23 14:11:43 2011, clonezone wrote: Show quoted text
> I would prefer that the change be a list of exempt modules. I don't > like the idea of having a whole class of modules being exempt.
I think this is not unreasonable, though if it's my fingers at the keyboard the list of exempt modules would probably be empty by default. There actually seem to me to be two issues: what the ticket asks for, and why it was filed. Why the ticket was filed: The motivation for the ticket is that DBIx::Class::Schema::Loader generates code that puts 'use utf8;' before the package declaration. If Unicode package names were supported by Perl, allowing 'use utf8' would be a no brainer. But 'perldoc utf8' says that Unicode package names are not supported, because a package name is, ultimately, a file name, and Unicode file names are not portable. This leaves me believing that it is a stylistic issue, and my feeling is that the title of the book should come before the first chapter, not after. Others may feel differently, but nobody makes anyone use any particular Perl::Critic policy. We have actually been around the "Code generator X generates the code this way so Perl::Critic should accept it" merry-go-round before (with Dist::Zilla and 'BEGIN { require 5.010; }' I believe). And it seems to me that what code generator X does is not relevant in and of itself. It's a question of whether what code generator X does makes sense. What the ticket asks for: The ticket generalizes the problem to asking for any pragma to be accepted before a package statement, justifying this by saying that pragmas are lexical in scope, and therefore span package boundaries. That's fine in theory, but the devil is in the details. The fact is that I know of no way to determine what is a pragma. Adam Kennedy solves this by saying it's a package with an all-lowercase name, and adding all sorts of caveats to the docs. By this definition, 'constant' is a pragma, but manifest constants declared with 'use constant' are scoped to the name space, not lexically. The only other way to recognize a lexically-scoped pragma I can think of is an exhaustive list, which will be out-of-date tomorrow. My conclusion, for what it's worth: What all this says to me is that it would be equally valid to file a ticket against DBIx::Class::Schema::Loader to get them to put the 'use utf8' after the package statement. Since my only reason for this is stylistic that does not mean that we reject the ticket. But it looks to me like a wish list item, with the implementation Elliot suggested.
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Fri, 25 Nov 2011 17:22:41 +0000 (GMT)
To: "bug-Perl-Critic [...] rt.cpan.org" <bug-Perl-Critic [...] rt.cpan.org>
From: Darius Jokilehto <dariusjokilehto [...] yahoo.co.uk>
Show quoted text
>On Wed Nov 23 14:11:43 2011, clonezone wrote:
>> I would prefer that the change be a list of exempt modules.  I don't >> like the idea of having a whole class of modules being exempt.
> >I think this is not unreasonable, though if it's my fingers at the >keyboard the list of exempt modules would probably be empty by default. >
[...] Show quoted text
> >My conclusion, for what it's worth: > >What all this says to me is that it would be equally valid to file a >ticket against DBIx::Class::Schema::Loader to get them to put the 'use >utf8' after the package statement. Since my only reason for this is >stylistic that does not mean that we reject the ticket. But it looks to >me like a wish list item, with the implementation Elliot suggested. > >
I did consider sending a patch to DBIx::Class::Schema::Loader instead of here, but I thought there may be a general use case for the patch with this Perl::Critic rule. I've gone ahead and altered the patch so as to exempt a list of modules given by the user, so it has a new option (exempt_modules). Is this more in line with what you intended? Thanks, Darius

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Fri, 25 Nov 2011 20:24:23 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 450b
From "perldoc perlmod" (with emphasis added): A package statement affects only dynamic variables‐‐including those you’ve used local() on‐‐but not lexical variables created with my(). Typically it would be the first declaration in a file included by the "do" "require", or "use" operators. Can anyone help me understand when/why a 'use' statement (for pragmata or otherwise) before the package declaration would be a good thing? -Jeff
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Sat, 26 Nov 2011 08:37:35 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 451b
On 11/25/11 8:24 PM, Jeffrey Thalhammer via RT wrote: Show quoted text
> Can anyone help me understand when/why a 'use' statement (for > pragmata or otherwise) before the package declaration would be a good > thing?
Actually, the case that inspired this is one. If one did not care about portability across filesystems (forget even operating systems), one could make clear that package names were Unicode via use utf8; package Some::ƒÚn::∏åçkågè;
Download (untitled) / with headers
text/plain 1.1k
On Sat Nov 26 11:37:39 2011, clonezone wrote: Show quoted text
> On 11/25/11 8:24 PM, Jeffrey Thalhammer via RT wrote:
> > Can anyone help me understand when/why a 'use' statement (for > > pragmata or otherwise) before the package declaration would be a
> good
> > thing?
> > Actually, the case that inspired this is one. If one did not care > about portability across filesystems (forget even operating systems), > one could make clear that package names were Unicode via > > use utf8; > package Some::ƒÚn::∏åçkågè;
Since the discussion here seems to have kind of petered out, I have committed a patch to allow configured modules to be imported before the package statement. The configuration option is 'allow_import_of', though I'm sure someone can think of a better name, and by default no imports are allowed. The patch submitted by the requester, while appreciated, was not used verbatim because of self-compliance concerns. And of course, if further reflection (and contemplation of the submitted code) says that we do not want this, the beauty of a source control system is that it can always be reverted. Oh. It's SVN revision 4098.
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Wed, 7 Dec 2011 13:45:58 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 357b
On Dec 5, 2011, at 12:08 PM, Tom Wyant via RT wrote: Show quoted text
> And of course, if further reflection (and contemplation of the submitted > code) says that we do not want this, the beauty of a source control > system is that it can always be reverted.
I find myself afflicted right now with the exact same problem as the OP. So I'm willing to bless this. -Jeff
Download (untitled) / with headers
text/plain 621b
On Wed Dec 07 16:46:11 2011, jeff@imaginative-software.com wrote: Show quoted text
> > On Dec 5, 2011, at 12:08 PM, Tom Wyant via RT wrote: >
> > And of course, if further reflection (and contemplation of the
> submitted
> > code) says that we do not want this, the beauty of a source control > > system is that it can always be reverted.
> > I find myself afflicted right now with the exact same problem as the > OP. So I'm willing to bless this. > > -Jeff >
Well, I guess the code had better be right then. PPI::Statement::Include->module() returned undef for 'use 5.010;', but in fact it returns. Corrected in SVN revision 4099.
Download (untitled) / with headers
text/plain 437b
On Thu Dec 08 18:59:27 2011, WYANT wrote: Show quoted text
> > Well, I guess the code had better be right then. > PPI::Statement::Include->module() returned undef for 'use 5.010;', but > in fact it returns. Corrected in SVN revision 4099.
Garbled. What I meant to say was The code committed in SVN revision 4098 assumed that PPI::Statement::Include->module() returned undef for 'use 5.010;', but in fact it returns ''. Corrected in SVN revision 4099.
Download (untitled) / with headers
text/plain 714b
On Thu Dec 08 19:04:20 2011, WYANT wrote: Show quoted text
> On Thu Dec 08 18:59:27 2011, WYANT wrote:
> > > > Well, I guess the code had better be right then. > > PPI::Statement::Include->module() returned undef for 'use 5.010;', but > > in fact it returns. Corrected in SVN revision 4099.
> > Garbled. What I meant to say was > > The code committed in SVN revision 4098 assumed that > PPI::Statement::Include->module() returned undef for 'use 5.010;', but > in fact it returns ''. Corrected in SVN revision 4099.
And the above was found in the throes of adding another configuration option, 'allow_perl_version', to allow the aforementioned 'use 5.010;' before the package statement. This was committed as SVN revision 4100.
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Thu, 8 Dec 2011 16:27:20 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 483b
On Dec 8, 2011, at 4:16 PM, Tom Wyant via RT wrote: Show quoted text
> And the above was found in the throes of adding another configuration > option, 'allow_perl_version', to allow the aforementioned 'use 5.010;' > before the package statement. This was committed as SVN revision 4100.
Does it make sense to have that as a separate option from allow_import_of? Would we gain anything by permitting this in the config: [Modules::RequireExplicitPackage] allow_import_of = 5.10 utf8 strict -Jeff
Download (untitled) / with headers
text/plain 2.2k
On Thu Dec 08 19:27:30 2011, jeff@imaginative-software.com wrote: Show quoted text
> > On Dec 8, 2011, at 4:16 PM, Tom Wyant via RT wrote: >
> > And the above was found in the throes of adding another
> configuration
> > option, 'allow_perl_version', to allow the aforementioned 'use
> 5.010;'
> > before the package statement. This was committed as SVN revision
> 4100. > > > Does it make sense to have that as a separate option from > allow_import_of? Would we gain anything by permitting this in the > config: > > [Modules::RequireExplicitPackage] > allow_import_of = 5.10 utf8 strict > > -Jeff
Well, to me it made sense for two reasons: First, 'use 5.010;' seems to me different semantically than 'use Foo;'. The first form specifies a version of Perl, the second loads a module. ExtUtils::MakeMaker considers them different, specifying modules via PREREQ_PM, and the minimum Perl with MIN_PERL_VERSION. Module::Build considers them less different, but looks at 'use 5.010;' as being more like requiring version 5.010 of pseudo-module 'perl'. So my read is that the Module::Build approach would be more like [Modules::RequireExplicitPackage] allow_import_of = perl utf8 strict Second, because though they are both represented by a PPI::Statement::Include, if the PPI object represents a 'use 5.010;' the module() method returns false and the version() method returns 5.010, whereas for 'use Foo;' the module() method returns 'Foo' and the version() method returns false. So the two constructions take separate paths through the code anyway. Unless I ignore Adam's take on the situation as well, and just use $elem->schild( 1 ) to retrieve the module/version. Honestly, though, the real reason for not just doing allow_import_of = 5.10 is that it just feels weird and fragile to me. Weird, because that syntax disallows 'use 5.x;' for any 'x' but that explicitly listed. Fragile because it the minimal implementation treats 'use 5.010;', 'use 5.10.0;', 'use v5.10;' as being different. The principal of least surprise says they ought all to be equivalent. Plus, it seems to me if we're really interested in restricting the version of Perl specified by 'use 5.x;', it should be a policy all on its own. Anyhow, that's my take. But I made this a separate commit so that it could be removed if it seemed on discussion to be a bad idea.
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Fri, 09 Dec 2011 07:10:48 -0600
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 1.1k
On 12/8/11 6:27 PM, Jeffrey Thalhammer via RT wrote: Show quoted text
> On Dec 8, 2011, at 4:16 PM, Tom Wyant via RT wrote: >
>> And the above was found in the throes of adding another >> configuration option, 'allow_perl_version', to allow the >> aforementioned 'use 5.010;' before the package statement. This was >> committed as SVN revision 4100.
> > Does it make sense to have that as a separate option from > allow_import_of? Would we gain anything by permitting this in the > config: > > [Modules::RequireExplicitPackage] allow_import_of = 5.10 utf8 strict
Interesting question because there's a big debate going on in 5p5 over what "use 5.xxx" means. As of 5.10, it means BEGIN { require 5.xxx; require feature; feature->import(:5.xx); } and the feature->import(...) is supposed to be inclusive of prior versions, i.e. import of :5.yy is supposed to include everything in :5.xx where yy > xx. That might not be the case. A feature may be added in 5.16, decided that it's deprecated in 5.18, and then removed from anything that declares it wants 5.20 (though still supported if you say "use 5.16" or "use 5.18"). So, really, for our purposes, "use 5.xx" should be treated as the equivalent of "use feature".
Download (untitled) / with headers
text/plain 1.6k
On Fri Dec 09 08:10:56 2011, clonezone wrote: Show quoted text
> On 12/8/11 6:27 PM, Jeffrey Thalhammer via RT wrote:
> > On Dec 8, 2011, at 4:16 PM, Tom Wyant via RT wrote: > >
> >> And the above was found in the throes of adding another > >> configuration option, 'allow_perl_version', to allow the > >> aforementioned 'use 5.010;' before the package statement. This was > >> committed as SVN revision 4100.
> > > > Does it make sense to have that as a separate option from > > allow_import_of? Would we gain anything by permitting this in the > > config: > > > > [Modules::RequireExplicitPackage] allow_import_of = 5.10 utf8 strict
> > Interesting question because there's a big debate going on in 5p5 over > what "use 5.xxx" means. As of 5.10, it means > > BEGIN { > require 5.xxx; > require feature; > feature->import(:5.xx); > } > > and the feature->import(...) is supposed to be inclusive of prior > versions, i.e. import of :5.yy is supposed to include everything in > :5.xx where yy > xx. That might not be the case. A feature may be > added in 5.16, decided that it's deprecated in 5.18, and then > removed from anything that declares it wants 5.20 (though still > supported if you say "use 5.16" or "use 5.18"). > > So, really, for our purposes, "use 5.xx" should be treated as the > equivalent of "use feature".
use v5.10 is now equivalent to: BEGIN { require v5.10; no feature; feature->import(':5.10'); } But there is a good possibility that, some time before 5.16, ‘use v5.10’ will not actually load feature.pm to do its work. So considering ‘use v5.10’ equivalent to ‘use feature’ may not be a good idea.
Download (untitled) / with headers
text/plain 1020b
Well, it seems that handling 'use 5.010;' is less obvious than I thought it was. Or, at least it is obvious different ways to different people. To summarize: Me: A separate configuration item, allow_perl_version. Jeff: No new option, just stick a version in allow_import_of. Me: OK, no new option, stick 'perl' in allow_import_of. Elliot: It's more like 'use feature' (implying to me the use of 'feature' rather than 'perl', but Elliot did not say this). Fr. Chrysostomos: This form of 'use' did not imply 'use feature' before 5.10, and may not by 5.16. So 'feature' may not be a good idea. At this point, I don't see consensus on how or whether to handle the 'use 5.010;' construct. It was _not_ requested in this ticket - I just noticed that CPAN::Meta starts use 5.006; use strict; use warnings; package CPAN::Meta; and tried to anticipate. So what I propose to do is to wait a few days to be sure there is no further debate. If there is none, I will back out SVN revision 4100 and note that in this ticket.
Download (untitled) / with headers
text/plain 1.3k
On Sat Dec 10 19:41:15 2011, WYANT wrote: Show quoted text
> Well, it seems that handling 'use 5.010;' is less obvious than I thought > it was. Or, at least it is obvious different ways to different people. > To summarize: > > Me: A separate configuration item, allow_perl_version. > > Jeff: No new option, just stick a version in allow_import_of. > > Me: OK, no new option, stick 'perl' in allow_import_of. > > Elliot: It's more like 'use feature' (implying to me the use of > 'feature' rather than 'perl', but Elliot did not say this). > > Fr. Chrysostomos: This form of 'use' did not imply 'use feature' before > 5.10, and may not by 5.16. So 'feature' may not be a good idea.
FYI, I’m not actually using this module. I just wanted to provide clarification as to the feature.pm status, so your decision could be more informed. I.e., I couldn’t care less what the outcome is. :-) Show quoted text
> > At this point, I don't see consensus on how or whether to handle the > 'use 5.010;' construct. It was _not_ requested in this ticket - I just > noticed that CPAN::Meta starts > > use 5.006; > use strict; > use warnings; > package CPAN::Meta; > > and tried to anticipate. > > So what I propose to do is to wait a few days to be sure there is no > further debate. If there is none, I will back out SVN revision 4100 and > note that in this ticket.
Download (untitled) / with headers
text/plain 553b
On Sat Dec 10 19:45:47 2011, SPROUT wrote: Show quoted text
> On Sat Dec 10 19:41:15 2011, WYANT wrote:
> > Fr. Chrysostomos: This form of 'use' did not imply 'use feature' > > before 5.10, and may not by 5.16. So 'feature' may not be a good > > idea.
> > FYI, I’m not actually using this module. I just wanted to provide > clarification as to the > feature.pm status, so your decision could be more informed. I.e., I > couldn’t care less what > the outcome is. :-)
Thank you. Much appreciated. An informed decision can still be stupid, but is less likely to be.
Download (untitled) / with headers
text/plain 205b
As proposed a couple ticket updates ago, in the absence of dissent, I have removed the allow_perl_version configuration option that was added in commit 4100. The removal was committed as SVN revision 4101.
Download (untitled) / with headers
text/plain 630b
On Sat Dec 10 21:48:02 2011, WYANT wrote: Show quoted text
> On Sat Dec 10 19:45:47 2011, SPROUT wrote:
> > On Sat Dec 10 19:41:15 2011, WYANT wrote:
> > > Fr. Chrysostomos: This form of 'use' did not imply 'use feature' > > > before 5.10, and may not by 5.16.
Indeed, it will not, as of perl commit 2fc860ee1e. Show quoted text
> > FYI, I’m not actually using this module. I just wanted to provide > > clarification as to the > > feature.pm status, so your decision could be more informed. I.e., I > > couldn’t care less what > > the outcome is. :-)
> > Thank you. Much appreciated. An informed decision can still be stupid, > but is less likely to be.
Download (untitled) / with headers
text/plain 843b
Le 2011-12-11 01:41:15, WYANT a écrit : Show quoted text
> Well, it seems that handling 'use 5.010;' is less obvious than I thought
The difference with 'use' statements is the scope on which they apply. Most "pragma" (lower-case module names) apply to lexical scope: strict, warnings, Perl version, utf8, byte, encoding... Some exceptions are well known: base, parent, constant. Most upper-case apply to the package scope as they import symbols into the package. So the rule for allowing a "use" statement before a "package" statement is the scope on which the imported module applies. Any lexical module should be allowed before the 'package' statement, except for stylistic reasons. But there is now easy rule to determine if a module is lexical. The only practical solution is a list of module names. -- Olivier Mengué - http://perlresume.org/DOLMEN
Download (untitled) / with headers
text/plain 504b
Le 2012-02-25 13:08:44, DOLMEN a écrit : Show quoted text
> Any lexical module should be allowed before the 'package' statement, > except for stylistic reasons.
I even think that it would be useful to make a policy that enforce that lexical packages used at the top scope must be used before a package statement. Because a file may contain multiple packages, and lexical modules (ex: strict, utf8) will not limit themselves to the package in which they are declared. -- Olivier Mengué - http://perlresume.org/DOLMEN
Subject: Re: [rt.cpan.org #72660] Exclude pragmas from Modules::RequireExplicitPackage
Date: Mon, 27 Feb 2012 10:37:02 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 926b
On Feb 27, 2012, at 2:36 AM, Olivier Mengué via RT wrote: Show quoted text
> I even think that it would be useful to make a policy that enforce that > lexical packages used at the top scope must be used before a package > statement. Because a file may contain multiple packages, and lexical > modules (ex: strict, utf8) will not limit themselves to the package in > which they are declared.
I am confused. To me, a "lexical" pragmata is one that is bound to the location where it is declared. strict and warnings fall into this category. Then there are "file-scoped" pragmata that apply to the entire file, regardless of where they are declared. I think utf8 falls in this category but not 100% sure. You can emulate a file-scoped pragmata by placing a lexical pragmata at the very beginning of a file. But that doesn't change the fact that it is still lexical (i.e. bound to a location). Someone set me straight please. -Jeff
Download (untitled) / with headers
text/plain 2.2k
On Mon Feb 27 13:37:17 2012, jeff@imaginative-software.com wrote: Show quoted text
> > On Feb 27, 2012, at 2:36 AM, Olivier Mengué via RT wrote: >
> > I even think that it would be useful to make a policy that enforce
> that
> > lexical packages used at the top scope must be used before a package > > statement. Because a file may contain multiple packages, and lexical > > modules (ex: strict, utf8) will not limit themselves to the package
> in
> > which they are declared.
> > I am confused. To me, a "lexical" pragmata is one that is bound to > the location where it is declared. strict and warnings fall into > this category. Then there are "file-scoped" pragmata that apply to > the entire file, regardless of where they are declared. I think > utf8 falls in this category but not 100% sure. You can emulate a > file-scoped pragmata by placing a lexical pragmata at the very > beginning of a file. But that doesn't change the fact that it is > still lexical (i.e. bound to a location). > > Someone set me straight please. > > -Jeff >
Me too. And let try to say why I'm confused. I understand the proposal to be for a policy that requires lexical pragmata declared at file scope to occur before the first 'package' declaration, if any. I won't comment on the merits of this policy. But presuming it can be written, it should not be in core Perl::Critic, unless the "zero-configuration" policy is dropped. I think the following dilemma shows this: Assume the proposed policy "knows" what all the lexical pragmata are. Then, if you run Perl::Critic out of the box (i.e. with no .perlcriticrc file), every module will violate either the proposed policy or Modules::RequireExplicitPackage. This does not sound like a good thing to me -- at least _I_ am not anxious to respond to the RT tickets this will cause. Assume the proposed policy does not "know" what all the lexical pragmata are. Then, the policy will do nothing unless the user configures the names of the pragmata. But that violates the "zero-configuration" rule. A further difficulty in writing the proposed policy is that nobody knows any way to identify lexical pragmas (or, for that matter, any pragma) other than to list them. Given the ferment that is CPAN, a built-in list would (I fear) be obsolete in short order.
RT-Send-CC: jeff [...] imaginative-software.com
Download (untitled) / with headers
text/plain 1.4k
Le 2012-02-27 19:37:17, jeff@imaginative-software.com a écrit : Show quoted text
> > On Feb 27, 2012, at 2:36 AM, Olivier Mengué via RT wrote: > I am confused. To me, a "lexical" pragmata is one that is bound to > the location where it is declared. strict and warnings fall into > this category. Then there are "file-scoped" pragmata that apply to > the entire file, regardless of where they are declared. I think > utf8 falls in this category but not 100% sure. You can emulate a > file-scoped pragmata by placing a lexical pragmata at the very > beginning of a file. But that doesn't change the fact that it is > still lexical (i.e. bound to a location).
File-scoped pragmata doesn't exists in itself. This is just a lexical pragmata outside any {} block, so at the top scope of the file. utf8/encoding are lexical pragmata. See the attached file that use multiple encodings in the same source. Use "perl -C enc.pl" to run it. My point is that when a file contains multiple packages, disallowing lexical pragmas outside packages doesn't help the user to understand what Perl does. In fact, it does the opposite, making think that the scope of pragma is the package. Here is an example: package A; use warnings; package B; $a = 5; 1; The "use warnings" applies to statements in package B as well as in package A. So I prefer to write my code like that: use warnings; package A; package B; $a = 5; 1; -- Olivier Mengué - http://perlresume.org/DOLMEN
Subject: enc.pl
Download enc.pl
text/x-perl 158b
use 5.010; { use utf8; say "Olivier Mengué"; } { use encoding "cp1252"; say "Olivier Mengué"; } { use utf8; say "Olivier Mengué"; }


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.