Keep imports and functions out of your namespace
http://search.cpan.org/dist/namespace-clean/
Keeping packages clean
When you define a function, or import one, into a Perl package, it will
naturally also be available as a method. This does not per se cause
problems, but it can complicate subclassing and, for example, plugin
classes that are included via multiple inheritance by loading them as
base classes.
The 'namespace::clean' pragma will remove all previously declared or
imported symbols at the end of the current package's compile cycle.
Functions called in the package itself will still be bound by their
name, but they won't show up as methods on your class or instances.
- Developed at devel:languages:perl
- Sources inherited from project openSUSE:Factory
-
3
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Factory:zSystems/perl-namespace-clean && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
| namespace-clean-0.22.tar.gz | 0000013228 12.9 KB | |
| perl-namespace-clean-use_lib.patch | 0000005280 5.16 KB | |
| perl-namespace-clean.changes | 0000003319 3.24 KB | |
| perl-namespace-clean.spec | 0000002614 2.55 KB |
Revision 6 (latest revision is 16)
Stephan Kulow (coolo)
accepted
request 103788
from
Stephan Kulow (coolo)
(revision 6)
- updated to 0.22
- Simplify the >= 5.10 PP variant even more - move the hook from
DESTROY into DELETE
- Force explicit callback invocation order on 5.8 PP
- Replace the %^H tie approach with fieldhashes, fixes all known
corner cases and caveats on supported perls >= 5.8.1 (FC)
- Compile away the debugger fixup on perls >= 5.15.5 (FC)
- More robust handling of the tied %^H in pure perl mode (RT#73402)
- Limit the debugger workarounds to perls between 5.8.8 and 5.14,
extend debugger support to all perl versions (FC) (RT#69862)
- If possible, automatically install (but not load) the debugger
workaround libraries on perls between 5.8.8 and 5.14 (RT#72368)
- Add back dropped NAME section (RT#70259)
Comments 0