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: : : http://search.cpan.org/dist/Acme-use-strict-with-pride/pride.pm : : Are we to discontinue use of [EMAIL PROTECTED], 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. Larry
