Graham Barr wrote:
>
> I would suggest that anyone want to contribute to this discussion should
> first read the thread about the addition of this pragma to perl5 in
> the perl5-porters archives
>
>
>http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragma&errors=0&case=on&maxfiles=100&maxlines=30
>
> Graham.
package chroot
would be more powerful than use namespace.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."
=head1 TITLE
package chroot
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 02 OCT 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
status: DEVELOPING
Number:
=head1 ABSTRACT
C<package chroot> is to Perl packages as C<chroot> is to filesystem directories.
This allows us a way to implement package name spaces hidden from each
other, and also a way to hide some methods of a package which is installed
within a "chroot jail."
=head1 DESCRIPTION
to rewrite perldoc -f package:
=item package chroot
=item package chroot NAMESPACE [, IMPORTKEY1 => IMPORTVAL1 [, IMPORTKEY2 => IMPORTVAL2
[, ...]]]
Declares the namespace root of the compilation unit as being in the
given namespace. The scope
of the chrooting is from the declaration itself through the end
of the enclosing block, file, or eval (the same as the C<my()> operator).
All further C<package> declarations within the chroot have the
NAMESPACE prepended to their NAMESPACEs.
Further C<package chroot> declarations will nest.
Within a chrooted environment, there is no way within the perl language
to access a variable from outside the chrooted environment without an
explicit accessor.
=item IMPORT PAIR list
Each item in the hash that follows the name of the new root package name space
is an alias mapping. The key is the name in the new name space and the value is the
name of the object in the old name space which is being imported with the new name.
Variables, subroutined, and entire packages may be imported into the chroot,
usually with their own names.
Situations in which one would want to change the names of imported items are
easy to imagine, for instace translations to other languages, or mocking up
of emulation environments in which one would like to hide perl keywords that
collide with keywords in the emulation.
=item KEY,VALUE
the key in the import pair is the name in the virtual space, the value
is the name in the general space. This is so you can add an entire set of
functionality, like CORE::, to the virtual space, and then take parts of it
away.
=item wild cards in import pairs
a wild-card character * is defined in
the import pair language. This allows all of the semantic descendents
of a package to be imported together. For instance:
package orig; # we are now in package orig::
package chroot C, # from here on in, all
# globals will have C:: prepended
# to their names
CORE:: => CORE::, # but builtins will be visible
'A::*' => 'A::', # and everything in A:: and A::...
'B::' => 'E::', # all symbols E::... will be aliased to
C::B::...
'$frog' => '$cat'; # and $C::orig::frog will be $orig::cat but
not @C::orig::frog or &C::orig::frog
'*main::frog' => '*main::frog'; # and $C::main::frog will be
$main::frog, and so will other whatzits associated with that name.
$A::inA = 'inA'; # sets $C::A::inA, AKA $A::inA
$B::inB = 'inB'; # sets $C::B::inB, BKB $E::inB
$A::B::inAB = 'inAB'; # sets $C::A::B::inAB, AKA $A::B::inAB
$B::A::inBA = 'inBA'; # sets $C::B::A::inBA only
$cat = 'meow'; # sets $C::orig::cat
$frog = 'meow'; # sets $C::orig::frog, AKA $orig::cat
A reference within the jail to a symbol that has appeared in an imported
package since the importing will refer to the same item as it would outside:
if you want to import only the symbols which exist at import time you
need to list them explicitly.
=head1 CONFLICTS
The requirement of an explicit namespace argument allows
package chroot;
to switch the current package to chroot:: like it does in Perl5.
=head1 IMPLEMENTATION
The root of the global symbol table becomes replacable.
C<CORE::package> will need to recognize this as a special case.
Wildcard imports could be implemented by adding code to the symbol resolver
so that it knows that the package C<A::B::> is "within" C<A::>.
the implementation of Packages may need to be altered so package has
a meaning greater than "what is by default prepended to otherwise
unqualified variables"
=head1 REFERENCES
Discussion around RFC 254 on overloading classes
