On 12/15/05, Gaal Yahas <[EMAIL PROTECTED]> wrote:
> What should this mean?
>
> package Foo;
> sub Bar::baz is export { ... }
>
> The problem is in how callers request this export.
>
> use Foo <baz>;
Hmm. My gut reaction is that that is the correct way to request that export.
> Looks weird, as this demonstrates:
>
> package Foo;
> sub baz is export { "I am Foo::baz" }
> sub Bar::baz is export { "I am Bar::baz" }
And that is certainly not allowed. Let's think about why.
It seems that there are two abstractions that are getting muddled into
one here, and that's what's causing the confusion. There's a package,
the thing that you put names in, and then there's the thing that you
"use".
Perhaps that latter thing is called a module, and a module's job is to
collect exports and export them. Saying "module Foo" opens up
"package Foo" as well as creating a scope for "is export"s to register
themselves.
module Foo;
package *Bar;
sub baz() is export {...} # defines Bar::baz() that is exported
when you use Foo
That seems like it could get a little bit tricky. Maybe module and
package are really competing for the same scope, so that in order to
get the behavior above:
module Foo {
package *Bar;
sub baz() is export {...}
}
And the first example would die with "baz() doesn't have anywhere to
be exported".
Hmm. Details aside, I think that's the right approach. The thing
that gets "use"d (or IMPORTed) it different from a package, and it is
the thing that collects exports. It collects them by basename only,
so that:
module Foo {
sub *Foo::baz() is export {...}
sub *Bar::baz() is export {...}
}
Is a name conflict in the exporter.
Luke
