develooper Front page | perl.perl6.language | Postings from July 2005

Re: User-defined infix subs/methods?

Thread Previous | Thread Next
Larry Wall
July 14, 2005 11:49
Re: User-defined infix subs/methods?
Message ID:
On Thu, Jul 14, 2005 at 09:19:29AM +0800, Autrijus Tang wrote:
: Within perl 5, there is an extremely easy way to write that, namely
: coderef in @INC that provides line-based filtering:
: Are we to discontinue use of coderef-in-@*INC, and switch to the
: slightly more difficult but far more manageable approach of rebinding
: &*require?

I suppose that depends in part on whether we want to guarantee the
@INC interface for Perl 6 at all.  Or it may be that we keep @INC but
make it point to abstract repositories rather than just directories.
And maybe some of those repositories have an interface with active
components.  Or maybe @INC is a list of repository locating commands
with optional arguments.  Maybe @INC is *all* closures that return
a package object or fail.  Maybe @INC is just a fancy rule.

I dunno.  Nobody's actually designed the library system yet.  It would
be nice if it degenerated to a simple file lookup in list of a simple
directories, I suppose, since that's the current Perl-think, but
that doesn't mean we have to cap the abstraction at the top.

I suppose what it comes down to is that we'll still have @INC, and
allow closures in it, and probably pull in the standard library with
a closure that knows how to load standard modules efficiently.  Whether
or not the standard library is represented by a closure in @INC, the
standard library needs to have some kind of placeholder in the list
so that users can put overrides in front of it or defaults in back of
it.  Or @INC has to be split into a @PREINC plus @POSTINC, but a single
@INC seems simpler, and also allows multiple "standard" libraries, as
long as there's some way to name them.


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