Re: Resolving 'prototype mismatch' warning

Bleh. Those modules are automatically importing names into main? Turn that crap off!

Update: It's worse than I thought. Both of those modules do EXPORT rather than EXPORT_OK. Ugh. Have you ever wanted to strangle a programmer with his own entrails?

Well, so... remember that Exporter::import imports the names into your current namespace, which is only main by default. So you could set up a separate namespace for each test. That would be one good way to avoid namespace pollution/collisions.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Comment on Re: Resolving 'prototype mismatch' warning Download Code

Replies are listed 'Best First'.
Re^2: Resolving 'prototype mismatch' warning by Corion (Patriarch) on Feb 15, 2016 at 14:22 UTC
GotToBTru suggested in the CB to use the `()` feature of use to prevent `->import` being called: `... eval "use $modulename (); 1"; ...` [download] That way, the pollution should be somewhat prevented.	[reply] [d/l] [select]
Re^2: Resolving 'prototype mismatch' warning by 1nickt (Canon) on Feb 15, 2016 at 14:36 UTC
Solved: Thanks jdporter and choroba and corion (for help in CB). By declaring a package name I can avoid the namespace collision: `if ( $compressor ) { my $namespace = 'My::' . $compressor; if ( ! eval "package $namespace; use $compressor; 1;" ) { die "Could not load $compressor - $@"; } else { ... } }` [download] And then I can access the imported subs through my namespace by forming the full sub name into a string and by turning off `strict refs`: `} else { my $compress = "My::$compressor\::compress"; no strict 'refs'; my $compressed = &$compress( $raw ); use strict 'refs'; }` [download] The way forward always starts with a minimal test.	[reply] [d/l] [select]