develooper Front page | perl.modules | Postings from October 1999

[RFC] Exporter::PkgAlias ?

Thread Next
John Porter
October 22, 1999 08:35
[RFC] Exporter::PkgAlias ?
Message ID:

I have a module which allows a module to specify
that it should be defined into one or more namespaces

Confused?  Here's an example (assumes my current
working name, Exporter::PkgAlias):

    # file Some/
    use Exporter::PkgAlias
        sub { <DATA> };
    sub some_func { ...
    # etc.

This example specifies that the module being loaded
may be "defined into", and subsequently known as,
any of the names in the list, i.e.
and that the text of the module definition should
be taken from the file's __DATA__ section.
Which name is actually used depends on which one
is the subject of an 'import' call.  In the absence
of any other direction, it will be the one which
some other code 'use'd, e.g.

    use Some::Package;

will cause this module to be loaded with that name.
(Of course, the code above must be present in the
appropriately named file, i.e. Some/ in
the @INC path.)

The practical effect of this is that the same
exact file may be named as Some/,, *and* Yet/Another/ -- perhaps by
symbolic or hard links -- and they will all be
'use'able by user code.

That is, 

	use Some::Package;

will have essentially the same effect as

	use Yet::Another::Name;

(the only differences occuring when the function
looks at and acts upon the package name by which
it was invoked.)

There is another invocation mode, by which the
caller may control more exactly which name(s) the
module gets loaded into.  This involves passing
the names as the keys of a hash, with the corresponding
values being flags indicating whether to load into
that name:

    # file Some/
    use Exporter::PkgAlias {
          'Some::Package' => 1,
          'AKA' => 0,
          'Yet::Another::Name' => 0, 
        sub { <DATA> };
    sub some_func { ...
    # etc.

This will cause the module to be loaded into
the Some::Package namespace, regardless of which
name it was 'import'ed as by perl.
The other names are still considered "aliases"
for the package, so that a subsequent 'import'
call with one of the other names still accesses
the same package definition text.
(However, lexical variables are NOT shared
between the various packages that have a
common "definition".)


Considering its function, I figured Exporter
would be the most appropriate top-level to put
this under, even though it does operates on
entire packages, rather than individual symbols.

John Porter

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About