S11 - Modules and export

[Aaron Sherman]

I'm still troubled by the export trait as I read S11. I like not having
to write a new subroutine in a procedural module and THEN go back up and
edit @EXPORT. That's good.

But, it seems to me that:

module MyHTML {
# Wherein I pretend to have written an HTML module
# but really just re-brand Perl5ish CGI.pm
use CGI :html4;
sub hr(...) is export;
sub p(...) is export;
...
}

is a lot of work to go through, and it also requires that I correctly
reproduce the prototypes (although if "..." worked as I have it above,
then that would not be a concern).

Can "is export" be applied to use? In other words:

module MyHTML {
use CGI :html4 is export;
}

Also, for those cases where you're writing a very large number of
functions whose only purpose is to pollute the namespace of the caller
(HTML is probably as good an example as any), it would be nice if I
could set up "is export" as the default:

module MyHTML does allexport {
sub empty_element(str $n, @tags) is noexport {
"<$n {join(" ",@tags)} />"
}
sub hr(*@tags) { empty_element('hr',@tags) }
sub br(*@tags) { empty_element('br',@tags) }
...
}

I personally don't like this style of programming, but that doesn't mean
it isn't used to good effect by others.
--
☎ 781-324-3772
✉ a...@ajs.com
☷ http://www.ajs.com/~ajs

[Larry Wall]

On Tue, Nov 09, 2004 at 05:20:50PM -0500, Aaron Sherman wrote:
: I'm still troubled by the export trait as I read S11. I like not having

: to write a new subroutine in a procedural module and THEN go back up and
: edit @EXPORT. That's good.
:
: But, it seems to me that:
:
: module MyHTML {
: # Wherein I pretend to have written an HTML module
: # but really just re-brand Perl5ish CGI.pm
: use CGI :html4;
: sub hr(...) is export;
: sub p(...) is export;
: ...
: }
:
: is a lot of work to go through, and it also requires that I correctly
: reproduce the prototypes (although if "..." worked as I have it above,
: then that would not be a concern).

The glib answer is that maybe some kinds of things should be hard.

The deeper answer is that you mustn't get confused by the fact that
these are declarations. The word "declaration" means something
quite different in Perl than in your typical language. In Perl,
"declaration" just means "some routine that just happens to be called
at compile time". And "syntax" means "some routine that just happens
to be called by the parser".

: Can "is export" be applied to use? In other words:

:
: module MyHTML {
: use CGI :html4 is export;

: }

Probably not with that exact syntax, since you can't mix ":" and "is"
like that, but there should certainly be some way of saying that
you're acting as a wrapper to another module. Synopsis 11 should
not be considered complete. It doesn't yet say anything about the
difference between lexical and package importation, for instance.
It's not even clear that "use" is always the right keyword.

: Also, for those cases where you're writing a very large number of

: functions whose only purpose is to pollute the namespace of the caller
: (HTML is probably as good an example as any), it would be nice if I
: could set up "is export" as the default:
:
: module MyHTML does allexport {
: sub empty_element(str $n, @tags) is noexport {
: "<$n {join(" ",@tags)} />"
: }
: sub hr(*@tags) { empty_element('hr',@tags) }
: sub br(*@tags) { empty_element('br',@tags) }
: ...
: }
:
: I personally don't like this style of programming, but that doesn't mean
: it isn't used to good effect by others.

It's my job to pick the right default. It's not my job to make that
default mandatory.

Larry