I presume you're working with the core team to make this the real Exporter in 5.9?
I haven't thought of that yet. Do you think I should be? Note that this module cannot *replace* Exporter(::Heavy), since supporting its @EXPORT/@EXPORT_OK/%EXPORT_TAGS syntax would violently undo all improvements :)
Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).
| [reply] |
| [reply] |
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).
| [reply] |