On Wed, Sep 20, 2000 at 04:15:13AM -0000, Perl6 RFC Librarian wrote:
> =head2 The Basics
>
> The new C<autoload> pragma would rely on an C<autoload.conf> file that
> was located in C<@INC> and looked something like this:
What happens when there are multiple C<autoload.conf> files in C<@INC>?
> A custom one could also be included in C<@INC> ahead of the system one
> so that a user could include their own definitions.
By this I assume multiple C<autoload.conf>s are appended together?
Later you say:
> C<autoload> should always use the last one in the list,
> since this will be the most recent one if the person
> is not actively maintaining the file (i.e., just letting
> it be appended to automatically).
If it always uses the "last one", then later C<autoload.conf>s need
to be prepended to earlier ones for what you say about C<@INC> to make
sense.
Anyway, the semantics of multiple C<autoload.conf> files needs nailing
down.
> use autoload '/home/nwiger/perl/autoload.conf';
I'd prefer that this be the *only* usage.
Or, something else ... The program could contain it's own autoload.conf
information after an C<__AUTOLOAD__> line (similar to C<__END__>
or C<__DATA__>).
> =head2 Extensions
>
> The C<autoload> pragma could be extended in several ways:
>
> 1. If duplicate modules or methods are found, <autoload> should
> issue messages like:
Always or on-demand (i.e. via use warnings)?
> =head1 MIGRATION
>
> None. This introduces new functionality.
What you have under "Module Installation" I'd've put under migration
if it is to be the expected scenario.
> =head2 Module Installation
>
> On installation, some part of the Perl module install driven by
> C<MakeMaker> would have to read the exported function list from a given
> module and append it to the C<autoload.conf> file.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
