Trey Harris writes:

> In a message dated Wed, 4 Oct 2006, Smylers writes:
> > Trey Harris writes: T
> > 
> > > I remember not so many years ago when there were a lot of modules
> > > floating around that required you to do "no strict" of various
> > > flavors in order to use them.
> > 
> > Really?  How?
> I wrote imprecisely.  Not to "use" them in the sense of C<use Package>, 
> but "use" in the sense of make use of them as described in the perldoc's 
> synopsis

No, your words were fine -- you successfully conveyed that meaning but
was still puzzled by it.

> --usually by dint of requiring undeclared package variables,
> barewords,

How can a module require undelcared package variables?  Surely a module
simply requires package variables, then it's up to you whether you
declare them or not?

> or symbolic refs.

I hadn't thought of that.  Have you got an example of that?  I'm still a
little surprised to hear there were "a lot of modules floating around"
doing this sort of thing.

> Alias is one example, there were others.

I've never used Alias, but from looking at its synposis I'd've thought
that judicious use of C<our> would permit code using the module to run
with C<use strict>.

> (For example, a package that had string constants defined as
> subroutines like C<sub ERRCODE() { "ERRCODE" }> would behave
> differently than one that assumed barewords would work, but both might
> use identical examples of C<moose ERRCODE> in their perldocs.)

Gotcha.  So a user of the latter module could put the error codes in
quotes to keep with C<use strict>, it's just that the module docs didn't
make this clear?  That sounds more like a documentation glitch than a
module which requires you to use C<no strict>.

> > > I still run across modules that need "no warnings".  (I won't name
> > > names, because some of their authors post to this list ;)
> > 
> > Again, I can't see how.  If you use C<use warnings> in your program then
> > it is lexically scoped and only affects your code, not that of other
> > files you load in.
> Again, I meant in code use,


> not in just loading--uninitialized value warnings being the main
> culprit there.

But any variable that I define I can initialize to prevent that warning
being emitted by my code.  And since C<use warnings> is lexical, it
doesn't matter what the module's code does, that won't emit warnings
just because I've enabled them in my code that uses the module.


Reply via email to