The one thing that I almost always notice when playing around in non Perl languages is how well Perl handles scoping.
There is one place in which Perl got it totally wrong though.
The value of the current package is lexically scoped:
package Foo; { package Bar; say __PACKAGE__; # prints Bar } say __PACKAGE__; # prints Foo
However, the notion of the current package during compilation is dynamically scoped, even between files:
# Foo.pm: package Foo; use Bar;
# Bar.pm: say __PACKAGE__; # prints Foo
In other words, if you don't declare a package at the top of the .pm file before doing anything, you are risking polluting the namespace of the module that called you. What's worse is that it can be unpredictable, only the first module to load Bar will leak into Bar.pm, so this could amount to serious debugging headaches.
Consider the following:
# Foo.pm: package Foo; use Moose; use Bar; sub foo { ... }
Now suppose a subsequent version of Bar is rewritten using MooseX::Declare:
use MooseX::Declare; class Bar { ... }
Guess which package the class keyword was exported to?
But maybe Bar was tidy and used namespace::clean; instead of making $foo_object->class suddenly start working, $foo_object->meta would suddenly stop working. And all this without a single change to Foo.pm.
Now imagine what would happen if Foo did require Bar instead of use…
Anyway, I think the point was made, always declare your package upfront or you risk pooping on your caller. Anything you do before an explicit package declaration is in no man's land.
I'm pretty sure a future version of MooseX::Declare will contain a specific workaround for this, but I still think it's a good habit to always start every file with a package declaration, even if it's made redundant a few lines down.
2 comments:
Sounds like a good candidate for a Perl::Critic policy.
@zby - It's already there (since 03-2008 at least):
Perl::Critic::Policy::Modules::RequireExplicitPackage
Post a Comment