RFC 74 (v3) Proposal to rename C<import> and C<unimport>

[email protected] (Perl6 RFC Librarian)
Newsgroups perl.perl6.language,perl.perl6.announce
Message-ID <[email protected]>
This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Proposal to rename C<import> and C<unimport>

=head1 VERSION

  Maintainer: Jonathan Scott Duff <[email protected]>
  Date: 8 Aug 2000
  Last-Modified: 1 Sep 2000
  Mailing List: [email protected]
  Version: 3
  Number: 74
  Status: Developing

=head1 ABSTRACT

C<import()> and C<unimport> should be C<IMPORT> and C<UNIMPORT>
respectively, in keeping with all of the other special-to-Perl names.

=head1 DESCRIPTION

The Perl documentation says that 

	use Module LIST;

is equivalent to 

	BEGIN { require Module; import Module LIST; }

so that C<use Module LIST> automatically calls the C<import> routine
for that module if it exists.  Thus C<import> is a routine that has
special meaning to Perl.  This RFC proposes that C<import> and C<unimport>
be renamed to C<IMPORT> and C<UNIMPORT> respectively.  This would be
consistent with the naming of all other subroutines that are special
to Perl.

Nathan Wiger <[email protected]> suggests that we create an C<import>
keyword (and I assume an C<unimport> keyword as well) that calls
C<import Module LIST>.  The author of this RFC would rather not add
new keywords.  However, I see no reason why the B<module> author
should not provide an C<import()> routine that is simply an alias for
C<IMPORT()>.

=head1 IMPLEMENTATION

Just change the names!

=head1 MIGRATION

The Perl5 -> Perl6 translator should provide a C<import> alias for the
C<IMPORT> routine to ease migration.  Likewise for C<unimport>.

=head1 REFERENCES

Perl 5.6.0 documentation

RFC 59: Proposal to utilize C<*> as the prefix to magic subroutines

Email from Nathan Wiger <[email protected]> that went to perl6-language
but I can't find at www.mail-archive.com  :-(
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.