On Fri, Dec 16, 2005 at 01:05:21PM -0800, Larry Wall wrote:
> I think we can certainly let the module specify the default when
> someone says
>
> use Module <$hownow>;
>
> rather than
>
> use Module :my<$hownow>;
>
> I suspect the notation for setting default on the module end is simply
> to allow tag pseudo-sets that specify it:
>
> my $hownow is export(:state); # override implicit :my default
Would uppercase work better to avoid clashes with user-defined tagsets?
I.e. <:STATE :LET :TEMP :ENV :MY :OUR :GLOBAL>. Except I'm not sure what
some of these mean as exportables.
If I export a var from one scope to another, that's fine; the caller
gets a differently scoped alias to the same memory. But what about
closed lexicals? What does this mean:
sub make_tag {
my $tag is export = shift;
{ "<$tag>{ @_ }</$tag>" };
}
Audrey suggested that perhaps only top-level lexicals should be
exportable.
> : Second, where does a module consumer communicate configuration requests
> : to the module?
> : (e.g., 'use Test::More "no_plan"'),
>
> Well, there's a lot to be said for ad-hoc, but yes, it would be good
> to get control of the various forms of adhocracy so we know which
> ones are necessarily ad hoc and which ones are that way accidentally.
A straightforward and Huffmanly unoptimized protocol would be to
stipulate an explicit configuration argument. &import can receive it as
a named arg.
use Test::More conf => "no_plan";
Alternatively disallow implicit my importation specs and treat everything
to the right of the module name syntactically as arguments to import,
with the parser picking out things it recognizes as imports and passing
everything else through.
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
