Re: Module Design strawman

A couple of API changes I think would make things cleaner:

You shouldn't have to have %EXPORTER as a global (use vars, our) variable. Instead (or additionaly), you should be able to pass a hashref (or just a hash?).
You should be able to specifiy hard references instead of symbol names. (Together, these two would let you avoid having any globals if you want -- and I want.)
Instead of having that single function call in what is otherwise a purely declarative API, have a key value of '' mean "symbol name same as export name". (Perhaps a value of undef should mean that the import is silently ignored -- I'm not sure if such a thing should be encouraged, though.)
Perhaps you could autogenerate the direct-callable functions (IE create a sub foo{} that calls the correct foo_old or foo_new, if sub foo doesn't exist).
Document that pragmata imports traditionaly begin with a - and can be implemented using \&figure_it_out.
Resolve the conflict I just created with exporting arrays and code via the reference syntax and the tag and \&figure_it_out syntax. (I really think that you should be able to export via hardrefs rather then symbolic refs, though.)
$EXPORT_DEFAULT_VERSION should be doable in the hash too, rather then as a seperate global. (Perhaps _Exporter_VA_defaultVersion.) Also, if it's not given, it should default to $VERSION, not have no default.

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Comment on Re: Module Design strawman - Exporter::VA

Replies are listed 'Best First'.
Re: Re: Module Design strawman - Exporter::VA by John M. Dlugosz (Monsignor) on Oct 07, 2002 at 15:15 UTC
You should be able to specifiy hard references instead of symbol names. (Together, these two would let you avoid having any globals if you want -- and I want.) Resolve the conflict I just created with exporting arrays and code via the reference syntax and the tag and \&figure_it_out syntax. (I really think that you should be able to export via hardrefs rather then symbolic refs, though.) I didn't do hard refs because of this conflict. I suppose you could say `foo => sub { \&foo_hard }` with the existing design. Any other design (additional decorations of some kind?) would need to be at least this simple. You shouldn't have to have %EXPORTER as a global (use vars, our) variable. Instead (or additionaly), you should be able to pass a hashref (or just a hash?). You mean right in the `use` line, like `use Exporter::VA (foo => 'foo_internal');` [download] Perhaps you could autogenerate the direct-callable functions (IE create a sub foo{} that calls the correct foo_old or foo_new, if sub foo doesn't exist). Wonderful. An inherited AUTOLOAD would do the trick. Instead of having that single function call in what is otherwise a purely declarative API, have a key value of '' mean "symbol name same as export name". I suppose that would be OK. Also, a special hash entry could list all the non-alias simple exports, instead of using a function call. Document that pragmata imports traditionaly begin with a - and can be implemented using \&figure_it_out. Sure. Is there any prior art on pragmatic imports other than version numbers? $EXPORT_DEFAULT_VERSION should be doable in the hash too, rather then as a seperate global. (Perhaps _Exporter_VA_defaultVersion.) Also, if it's not given, it should default to $VERSION, not have no default. If not given, default to the same version number as the Exporter::VA's version? I don't get it. Everything in the hash: Sure could. But I think it should be clearer than that. Thanks for your thoughts. That was all very useful feedback. Stay tuned for the next iteration. —John	[reply] [d/l] [select]
Resolve the conflict by John M. Dlugosz (Monsignor) on Oct 16, 2002 at 18:41 UTC
re: Resolve the conflict I just created with exporting arrays and code via the reference syntax and the tag and \&figure_it_out syntax. (I really think that you should be able to export via hardrefs rather then symbolic refs, though.) See callback or call now?.	[reply]