Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand

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]