Maybe you could have an Exporter::Tidy::Compat as a drop in replacement to translate the Exporter interface to the Exporter::Tidy one?

The two modules have different goals, and there is no easy way to translate things automatically.

Exporter(::Heavy)	Exporter::Tidy
import() is inherited	import() is imported
Uses EXPORT globals	Gets information during importing
Supports tagless operation	Everything must be in a tag
Supports symbol exclusion	If you request a tag, you always get it entirely
Supports pattern matching	Does not support pattern matching
Lets you handle unknown symbols (Foo->export_fail)	Unknown symbols are not exportable, period
Uses numbers to require versions (Foo->require_version)	Doesn't do any version checking
Can export to different levels	Always exports to its own caller

Exporter::Tidy can only be this small and fast if it doesn't support those features.

Should Exporter::Tidy ever become the standard exporter, Exporter could then become a stub to load Exporter::Tidy::Compat.

Should Exporter::Tidy ever be renamed to Exporter, then the current Exporter should be named Exporter::Compat, and the new Exporter would need to use AUTOLOAD to load it and goto its methods. And the same if $_[0] ne __PACKAGE__ during import().

But I think it's better to have different names for different things. What do you think, merlyn and Aristotle?

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

I think that comparison list is an exellent candidate for your nascent FAQ, or perhaps a subsection in the regular Exporter::Tidy documentation. For those that care what exporter modules actually do, this answers lots of questions.

Matt

I would consider it a mistake to ever rename Exporter::Tidy to Exporter - Exporter should never offer Exporter::Tidy semantics. Newer code should fail for absence of Exporter::Tidy on old platforms, not for lacking support of its semantics in the then current Exporter: simply installing Exporter::Tidy is much easier than replacing the entire Exporter package.

I'm also not saying Exporter::Tidy should support the Exporter features at all. It would be the sole responsibility of Exporter::Tidy::Compat to translate.

Looking at the list though, I'm wondering whether it would make any sense at all.. supporting some of them would obviously require modifications to the import() that would water down the whole thing. Limitations on what could be done without changing Exporter::Tidy's import() would be acceptable IMO, but "user visible" changes to the interface are not. On those grounds, consider my suggestion retracted.

Makeshifts last the longest.