Re: Really auto autoloaded modules
At 01:41 PM 2/1/2001 -0500, Michael G Schwern wrote: On Thu, Feb 01, 2001 at 12:24:38PM -0600, Dave Rolsky wrote: Here's a gross thought (for implementors at least ;) If it sees use CGI qw( param header ); the autoloader could look for a module which implements the 'CGI' interface and has those two functions. Problem is, its extremely difficult to figure out what module implements what. Right, which is one of the reasons why this is going to be explicit. No magic here--there's too much potential for things to get badly messed up. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Really auto autoloaded modules
Dan Sugalski wrote: The last thing I want is for every module to automagically export all (or even some) of its functions. That way lies namespace pollution *real* fast. I don't see why this is a concern. Unless some explicit arrangement is made for CGI to export param (following the example), a call to unqualified param() in user code shouldn't find CGI::param, automagically loaded or otherwise. Namespaces is an orthogonal issue, I think. And so the problem of autoloading non-core definitions is minimized; if I call CGI::param explicitly, there's only a few places it can reasonably be expected to come from. Vs. calling something like time(), which can only come from someplace that defines it Iin the main:: space (or whatever is the current default namespace) , including by export from some other namespace. -- John Porter A pessimist says the CPU is 50% utilized. An optimist says the CPU is 50% unutilized. A realist says the network is the bottleneck.
Re: Why shouldn't sleep(0.5) DWIM?
[EMAIL PROTECTED] wrote: John Porter wrote: we would only implement changes that add something desirable. How does removing time() add something desirable? I'm not motivated to give an answer to that, because I'm not arguing in favor of removing time(). -- John Porter
Re: Really auto autoloaded modules
At 11:01 AM 2/2/2001 -0500, John Porter wrote: Dan Sugalski wrote: The last thing I want is for every module to automagically export all (or even some) of its functions. That way lies namespace pollution *real* fast. I don't see why this is a concern. Unless some explicit arrangement is made for CGI to export param (following the example), a call to unqualified param() in user code shouldn't find CGI::param, automagically loaded or otherwise. It's the explicit exporting that I'm concerned about. Perhaps I'm being overly worried, but it strikes me that if all a module needs to do to get on the autoload list is have an @EXPORT_AUTO declaration at the top (or something similar) we're going to see it abused rather badly. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Really auto autoloaded modules
Dan Sugalski wrote: It's the explicit exporting that I'm concerned about. Perhaps I'm being overly worried, but it strikes me that if all a module needs to do to get on the autoload list is have an @EXPORT_AUTO declaration at the top (or something similar) we're going to see it abused rather badly. Hm. Then maybe that's something you don't allow. I.e. if a module Foo wants to define bar() that gets autoloaded when called as bar() from main::, it has to define it in main:: (a practice which is already strongly discouraged). Otherwise, it can be autoloaded when called qualified as Foo::bar(). Otherwise, can't use the automagical loading for that sub. Eh? And it seems strange to suggest it for packages like Foo anyway; we already have autoloader. And that just emphasizes that this feature was meant for core functions. And, btw, perhaps we need to provide a way to un-load a loaded definition. This would be needed for, eg., migratory code. Or even just long-lived perl processes like mod_perl. -- John Porter A pessimist says the CPU is 50% utilized. An optimist says the CPU is 50% unutilized. A realist says the network is the bottleneck.
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
I recalled hearing about a language where
you set the return value of a function by
assigning to the name of the function within the function body,
Fortran and Pascal do that. Maybe others.
It would mean that
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
But that raises a potential conflict with another proposed magical
meaning of the subname within the sub: as a label for the beginning
of the sub. I.e.
sub foo {
bar();
}
is effectively
sub foo {
foo:
bar();
}
so that, for example, redo works kinda like the perl5 goto foo:
sub foo {
bar();
redo; # which is shorthand for:
redo foo; # like goto foo;
}
Proposals along these lines came up in the thread "$a in @b",
in the subsequent discussion of RFC 199, and probably in other
threads.
--
John Porter
A pessimist says the CPU is 50% utilized.
An optimist says the CPU is 50% unutilized.
A realist says the network is the bottleneck.
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
To answer my own question, the thing I found annoying about the syntax
when it was shown to me was that it seemed to break portability: you can't
cut from a function called A that returns something by assigning to A and
paste into a function called B to get the same functionality.
Maybe that's a good thing, by discouraging cargo-culting.
Another issue is, what is the scope of the symbol?
AFAICT, it can't be lexical and it can't be dynamic.
The former, because it can't be closed over:
sub foo {
return sub {
foo = 5;
}
}
$cr = foo();
$cr-(); # what just happened?!
And it being dynamic is problematic too:
sub foo {
foo = 4; # supposed to work, but...
}
foo = 6; # makes no sense!
make $__ mean "An alias for the
L-value of what the subroutine return value will get assigned to, or
${undef} if we're not invoked as an R-value."
I think that's unnecessarily baroque. Just let $__ be an alias
to the return value stack, the place where return() puts its
args anyway. In fact, shouldn't it be @__ ?
Too bad it's too late to write an RFC...
--
John Porter
A pessimist says the CPU is 50% utilized.
An optimist says the CPU is 50% unutilized.
A realist says the network is the bottleneck.
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 11:47:43AM -0500, John Porter wrote: And isn't this rather off-topic for this list? Sounds more like an internals thing... No. I think this is an area where the language should lead. I also think we need to define what an 'interface definition' should look like and/or define before we go much further. Tim.
RE: Really auto autoloaded modules
Dan Sugalski wrote:
It's the explicit exporting that I'm concerned about.
Perhaps I'm being overly worried, but it strikes me that
if all a module needs to do to get on the autoload list
is have an @EXPORT_AUTO declaration at the top (or
something similar) we're going to see it abused rather badly.
I'm a little confused:
o Michael Schwern's AnyLoader allows you to autoload modules
when you explicitly qualify a function from that module.
o Dan Sugalski is talking about pre-registering certain 'core'
functions so that their module is loaded if they are called
_without_ explicity qualifying their package.
I like the idea of making it easier to load and import modules.
o It is one less thing for the novice perl programmer to think about.
o If the standard library has conflicting interfaces, i.e. overlapping
function names... perhaps we could do this in a manner that would
help us find them and 'fix' them faster
o If you're worried about abuse, make Cuse strict/C disallow it
and Cno strict 'load'/C allow it.
Michael Schwern's AnyLoader is a bit strange though. To use an explicitly
qualified function if the only perceivable gain were to allow you to skip
needing an 'use'. After all, if the purpose is to mangle your namespace...
why are you explicitly calling a function in the first place? But that
isn't the main reason for AnyLoader is it?
Perhaps it makes more sense in the context of things like:
o Loading OO mods and oddballs like
Class::Contract-contract {};
$dbh = DBI-connect( ... );
o Interfaces as in Tim Bunce's suggestion:
Tim Bunce wrote:
Don't forget that it should tie in with the concept of defining
'interfaces' so
use Foo qw(bar);
may actually just load an interface definition and that definition
can be (lazily) bound to one of several alternative implementations
of the Foo interface (one XS and one pure-perl, for example).
Basically I'm saying that transparent autoloading should be an
attribute of the interface definition.
John Porter wrote:
And it seems strange to suggest it for packages like Foo anyway;
we already have autoloader. And that just emphasizes that this
feature was meant for core functions.
Incorporating something like Michael Schwern's AnyLoader for explicitly
qualified functions would be geared more at the standard and extended
libraries. Dan Sugalski's need to autoload modules from unqualified function
names is a slightly different problem domain. Those function names would be
determined and registered I assume when Perl itself is built / installed /
configured.
Re: Really auto autoloaded modules
John Porter wrote: Well, Java has interfaces, but I'm pretty sure that's not where we want to go; they're very OO-specific. And Corba likewise. -- John Porter
Re: Really auto autoloaded modules
Tim Bunce wrote: I also think we need to define what an 'interface definition' should look like and/or define before we go much further. Well, Java has interfaces, but I'm pretty sure that's not where we want to go; they're very OO-specific. Instead, probably Modula (/Modula3/Oberon) provide a better pattern to follow. -- John Porter You can't keep Perl6 Perl5.
Re: Really auto autoloaded modules
On Thu, 1 Feb 2001, Michael G Schwern wrote:
Problem is, its extremely difficult to figure out what module
implements what. Sure, if you see a Csub foo {...} you have a
I wasn't clear. I was thinking that somehow a module would register with
the core what interfaces it support when it is installed. Anything else
is madness (ok, my idea is madness too).
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Really auto autoloaded modules
At 01:00 PM 2/2/2001 -0600, Dave Rolsky wrote:
On Thu, 1 Feb 2001, Michael G Schwern wrote:
Problem is, its extremely difficult to figure out what module
implements what. Sure, if you see a Csub foo {...} you have a
I wasn't clear. I was thinking that somehow a module would register with
the core what interfaces it support when it is installed. Anything else
is madness (ok, my idea is madness too).
Your idea's not madness--it is, in fact, what I'm looking for us to define.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Really auto autoloaded modules
I wasn't clear. I was thinking that somehow a module would register with the core what interfaces it support when it is installed. Anything else is madness (ok, my idea is madness too). Your idea's not madness--it is, in fact, what I'm looking for us to define. A gut feeling that I have is we can't simply go by interface 'names', be they just simple names of funtions/methods or their full 'signatures' (let us not even start on (1) how difficult with Perl's type system and functions it is to define signatures (2) the difficulty in defining an ontology/vocabulary), either would not really be enough. What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual. (Java does a very similar thing but they propose embedding the DNS name as part of the package name: I think they the right idea but the proposed implementation sucks.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: assign to magic name-of-function variable instead of return
On Fri, Feb 02, 2001 at 08:09:36AM -0500, Charles Lane wrote: Peter Scott [EMAIL PROTECTED] wrote: At 07:12 PM 2/1/01 -0600, David L. Nicol wrote: I recalled hearing about a language (was it java?) where you set the return value of a function (was it VB?) by assigning to the name of the function within the function body, so the last line would be fname=rval; or fname could be used instead of rval all through it. Ah, an homage to Pascal :-) More like Fortran: REAL FUNCTION FOO(A) REAL A C FOO = 2*A+3 RETURN END ^^^ note exactly 7 spaces... And I think Fortran has a better claim to priority ;) And then there's Parse::RecDescent Abigail
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 01:17:35PM -0600, Jarkko Hietaniemi wrote: What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual. (Java does a very similar thing but they propose embedding the DNS name as part of the package name: I think they the right idea but the proposed implementation sucks.) Well, what you're looking for is a universaly unique identifier. Our current way for doing that is with a module name and a version number. That's nice and reasonable, but relies on two different modules not having the same name. That's not neccessarily a reasonable assumption. Sun's method takes some existing universaly unique thingy (domain names), then assumes that the unit identified (the domain name) can orgnize itself past that point. This might not be true of, say, the customers of an ISP. MS's method relies on 512-bit constants (GUIDs, like df5e0ce6-4def-4d6d-a47c-7d00cfffe1ae), which are chosen to have a low probablity of repitition (they incorporate the time and the MAC address of the network card, and some other random stuff). I think the current method is probably best for us. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 02:36:43PM -0500, James Mastros wrote: On Fri, Feb 02, 2001 at 01:17:35PM -0600, Jarkko Hietaniemi wrote: What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual. (Java does a very similar thing but they propose embedding the DNS name as part of the package name: I think they the right idea but the proposed implementation sucks.) Well, what you're looking for is a universaly unique identifier. I'm looking for a *hopefully* unique enough id that's also user friendly. A DNS name is assuming too much about the organizational structure and a mile long hex digit isn't very friendly, and neither of them is very descriptive. "XPG4 SysV IPC" would be. (I just made that one up.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 01:47:29PM -0600, Jarkko Hietaniemi wrote: A DNS name is assuming too much about the organizational structure and a mile long hex digit isn't very friendly, and neither of them is very descriptive. "XPG4 SysV IPC" would be. (I just made that one up.) Oh, I quite agree with your first (as quoted) sentance. I just don't see how as "XPG4 SysV IPC" is any better then IPC::SysV::XPG4. And /neither/ of them is good enough to be a contract name -- I'm certian that there's more then one possible way to bind XPG4's SysV IPC scheme into perl. (And I don't even know what XPG4 is.) Speaking of contract names, is Damien about? -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 02:57:20PM -0500, James Mastros wrote: On Fri, Feb 02, 2001 at 01:47:29PM -0600, Jarkko Hietaniemi wrote: A DNS name is assuming too much about the organizational structure and a mile long hex digit isn't very friendly, and neither of them is very descriptive. "XPG4 SysV IPC" would be. (I just made that one up.) Oh, I quite agree with your first (as quoted) sentance. I just don't see how as "XPG4 SysV IPC" is any better then IPC::SysV::XPG4. And /neither/ of Alone as such it wouldn't be, and it even couldn't be 100% true since the XPG4 binding is for C, but let's make it "XPG4 SysV IPC [EMAIL PROTECTED]". them is good enough to be a contract name -- I'm certian that there's more then one possible way to bind XPG4's SysV IPC scheme into perl. (And I don't even know what XPG4 is.) A UNIX standard. I guess nowadays we should be doing SUS instead. Speaking of contract names, is Damien about? The Australien mad professor should be around. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Really auto autoloaded modules
Speaking of contract names, is Damien about? No, but when you summon the AntiChrist, I sometimes appear instead. ;-) Damian
Re: Really auto autoloaded modules
Jarkko Hietaniemi wrote: A gut feeling that I have is we can't simply go by interface 'names', be they just simple names of funtions/methods or their full 'signatures' What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual. I rather like the idea that contract names are themselves namespace names. A contract version's name is thus defined within that contract's namespace. E.g. "specifies Foo::Bar" -- I specify a contract. "implements Foo::Bar::quux" -- I implement the Foo::Bar contract, specifically the quux version thereof. In any case, version idents should be legal perl identifiers; they can't really be numbers, since they are not inherently ordered. I could number *mine* jdp1, jdp1_1, etc., if I want... -- John Porter You can't keep Perl6 Perl5.
RE: Really auto autoloaded modules
From: James Mastros [mailto:[EMAIL PROTECTED]] Speaking of contract names, is Damien about? In Class::Contract... the package name is the unique identifier. Piers Cawley has been working on Interface::Polymorphism http://search.cpan.org/search?dist=Interface-Polymorphism Perhaps he has some insight to share? This ties into a concern I have with Perl 6. If I write a module that depends on the Bar and Baz modules, which themselves require different incompatible versions of module Foo... How will that work under Perl 6? $Foo::VERSION eq 1.00 | | $Foo::VERSION eq 2.00 | | Bar Baz \ / My::Module Garrett
Re: Really auto autoloaded modules
I rather like the idea that contract names are themselves namespace I rather dislike it: I think we are trying to stuff to much information on the package namespaces. names. A contract version's name is thus defined within that contract's namespace. E.g. "specifies Foo::Bar" -- I specify a contract. "implements Foo::Bar::quux" -- I implement the Foo::Bar contract, specifically the quux version thereof. In any case, version idents should be legal perl identifiers; I have no problem with that as long as we allow *all* characters in Perl identifiers. Yes, do I mean *all*. they can't really be numbers, since they are not inherently ordered. I could number *mine* jdp1, jdp1_1, etc., if I want... And for the the next J. D. P. person that comes along we say "tough luck"? No thanks, that's exactly the same mess we are now with the package names. -- John Porter You can't keep Perl6 Perl5. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Really auto autoloaded modules
Jarkko Hietaniemi wrote: I rather like the idea that contract names are themselves namespace I rather dislike it: I think we are trying to stuff to much information on the package namespaces. Well, I didn't say *package* namespace; I'm just pointing out that contract names can probably use the same kind of hierarchical categorization that other names do. And for the the next J. D. P. person that comes along we say "tough luck"? No thanks, that's exactly the same mess we are now with the package names. When you come up with a solution to this problem, please send an email to ICANN. -- John Porter You can't keep Perl6 Perl5.
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 03:54:33PM -0500, John Porter wrote: Jarkko Hietaniemi wrote: I rather like the idea that contract names are themselves namespace I rather dislike it: I think we are trying to stuff to much information on the package namespaces. Well, I didn't say *package* namespace; I'm just pointing out that contract names can probably use the same kind of hierarchical categorization that other names do. Ahh, okay. luck"? No thanks, that's exactly the same mess we are now with the package names. When you come up with a solution to this problem, please send an email to ICANN. I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator isn't one. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 03:07:12PM -0600, Jarkko Hietaniemi wrote:
I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator
isn't one.
Hmm. Though, perhaps, Commerce::WebCart::[EMAIL PROTECTED]::v1.0 would be.
I think the Java solution is basicly good, except for a few things:
1) Making the class name the same as the contract's name. I want to have
a sub Commerce::WebCart::checkout, not
Commerce::Webcart::{[EMAIL PROTECTED]}::v1.0::checkout.
2) Putting the uniquifying part before the meaning part. I care first if
it's about math or strings, not if it was written at a .com, a .net, or a
.mars.
3) Assuming that the entire domain name is one administrative zone.
[EMAIL PROTECTED] could have a completly different Commerce::WebCart
package.
BTW, I agree that contracts are not even a partaly ordered set, but that
doesn't mean we can't use version-vector number notation (1.2.3.4, v1.0) for
them. You should be able to use (at least) any valid identifier. And the
only rules about valid identifers are that they can't begin with certian
characters (0-9, some others I think), and that they can't contain two
consecutive colons. (or "'"s, but that's going to be thrown out, I assume).
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
At 02:08 PM 2/2/2001 -0800, Nathan Wiger wrote: Dave Rolsky wrote: That's what I was thinking. The point is that the module identifies the services it provides. Multiple modules may provide overlapping sets of services. Modules could also be somehow ranked (memory usage and speed come to mind). Then I could put this into my module: needs CGI; needs URI; needs HTML::Output; needs HTTP; First off, let me say that I like the autoloading idea, and tying it in with class contracts, and all that in theory. However, it also seems that this is getting *really* complicated really quickly. I'd agree. I was picturing the file the parser used reading something like: socket|Socket|1.0|gt to indicate that seeing a socket sub loaded in Socket v1.0 or higher, with some corresponding way in the Socket module to add that line into the parser's magic file. Folks seem to be getting a little out of hand, but it might get something useful, so I'm hesitant to stop things quite yet. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Really auto autoloaded modules
However, it also seems that this is getting *really* complicated really
quickly.
I'd agree. I was picturing the file the parser used reading something like:
socket|Socket|1.0|gt
I think this is the way to go. I'd suggest that the syntax be easier for
humans (or at least JAPHs ;-) to intepret, and that the condition be
fully generalizable. Something like:
autouse Socket::socket { $Socket::VERSION = 1.0 }
autouse Text::Reform::format{ 1 }
autouse Power::socket { $ENV{WIRED} }
Note that under RFC 128, Cautouse could actually be a vanilla
Perl subroutine defined by the parser:
my %autousage;
sub autouse (""qualified_name, condition) {
my ($package, $name) = $qualified_name =~ m/(.*)::(.*)/;
push @{$autousage{$name}},
{ package = $package, condition = $condition };
}
Then the parser could just do the file to load its autoloading information.
And when it comes time to resolve unknown subroutine calls, it takes the
first candidate for the name whose condition is satisfied:
UNKNOWN: foreach $sub ( @unknowns ) {
foreach $possibility ( @{$autousage{$sub}} } {
resolve($sub, $possibility-{package}) and next UNKNOWN
if $possibility-{check}-();
}
push @unresolved, $sub;
}
Or else it checks all the candidates and resolves only if there is exactly one
whose condition is satisfied, generating an "Ambiguous subroutine..." error
if more than one condition is fulfilled.
Damian
Re: assign to magic name-of-function variable instead of return
On Thu, Feb 01, 2001 at 07:12:31PM -0600, David L. Nicol wrote:
Looking over some C code of the form
int fname(char *param){
int rval;
...
return(rval);
}
I recalled hearing about a language (was it java?) where
you set the return value of a function (was it VB?) by
assigning to the name of the function within the function body,
so the last line would be
fname=rval;
or fname could be used instead of rval all through it.
This obviously allows the compile-time optimization of using the
lvalue the function will be getting assigned to directly, one fewer
temporary storage space, as well as saving keystrokes.
Did anyone ever (before) suggest adding this to perl? It would mean
that
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
Does that mean there's going to be a @__ as well, for uses in list context?
If so, what happens with:
sub some_sub {
@__ = qw /foo bar baz/;
}
my $fnord = some_sub;
If there isn't going to be a @__ of some sorts, how is the case of the sub
being called in list context going to be handled?
Abigail
Re: Really auto autoloaded modules
Where should this info be maintained? In a module in @INC (sort of like
CPAN/MyConfig.pm)? Or in a special file that's only written to via a
module install? Or in a block atop each module that's yanked out via
MakeMaker? Or???
The parser needs to have it in a standard system-wide place.
I wasn't actually proposing it as a replacement mechanism for Exporter,
but if that standard configuration file included the line:
autouse STD::autouse { 1 }
then I suppose any other module could replace:
@EXPORT = qw( foo bar );
with:
autouse foo {1}
autouse bar {1}
Which implies we might make use of RFC 128's variadic parameters feature and
the proposed multi-valued Cforeach to implement autouse as:
sub autouse ( ("", ) : repeat {
foreach my ($qualified_name, $condition) (@_) {
my ($package, $name) = $qualified_name =~ m/(.*)::(.*)/;
push @{$autousage{$name}},
{ package = $package, condition = $condition };
}
}
and treat ourselves to:
autouse foo {1}, bar {1};
I suppose this also implies a Crequested subroutine (Cautouse'd,
of course :-) within modules -- so that one can replace:
@EXPORT_OK = qw( only by request );
with:
autouse only{requested},
by {requested},
request {requested},
;
H. Tidy, but too tedious perhaps?
Damian
Re: Really auto autoloaded modules
Damian Conway wrote:
Where should this info be maintained? In a module in @INC (sort of like
CPAN/MyConfig.pm)? Or in a special file that's only written to via a
module install? Or in a block atop each module that's yanked out via
MakeMaker? Or???
The parser needs to have it in a standard system-wide place.
Hmmm. I see what you mean, but why couldn't it be in @INC, first one
wins? The file could be named AutoUse.pm or something.
I would assume that 'use' would be done before 'autouse', so any 'use
lib' statements would already be taken into account? I'm probably
missing something super-obvious, so please point it out if so.
I wasn't actually proposing it as a replacement mechanism for Exporter,
but if that standard configuration file included the line:
autouse STD::autouse { 1 }
then I suppose any other module could replace:
@EXPORT = qw( foo bar );
with:
autouse foo {1}
autouse bar {1}
What about making it into a 'use overload' style declaration to decrease
the tedium? No need for multi-value foreach necessarily:
autouse foo = {1}, bar = {1};
...replace:
@EXPORT_OK = qw( only by request );
with:
autouse only{requested},
by {requested},
request {requested},
;
H. Tidy, but too tedious perhaps?
Yeah, a little too tedious. For the EXPORT thingy it seems a different
pragma would be more fitting:
use export always = [qw(you get this)],
request = [qw(only by request)],
tags = { cgi = [qw(param etc)] };
Then the key request would point to the applicable thingies. Just like
@EXPORT_OK but w/ a pragma.
I actually wasn't proposing that autouse replace @EXPORT either, but
this is may be a worthwhile brainstorming thread...
-Nate
Re: Really auto autoloaded modules
I would assume that 'use' would be done before 'autouse', so any 'use
lib' statements would already be taken into account? I'm probably
missing something super-obvious, so please point it out if so.
No. Cuse before Cautouse was my assumption too.
Yeah, a little too tedious. For the EXPORT thingy it seems a different
pragma would be more fitting:
use export always = [qw(you get this)],
request = [qw(only by request)],
tags = { cgi = [qw(param etc)] };
I like that, though I'd go with different key names ("always" isn't
always, and "tags" is not well related to its effect). How about:
use export implicit = [qw(you get this)],
explicit = [qw(only by request)],
complicit = { cgi = [qw(param etc)] };
(Sorry, couldn't resist that third one: it probably should be "grouped",
or "aliased", or something more pedestrian and obvious, but the triple
suffix makes such a great mnemonic :-).
I really do like this, especially if the package's Cimport is still called,
when it's in effect. All too often I want the convenience of Exporter, but
I need to twiddle the import semantics too.
Damian
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 11:56:50AM -0600, Garrett Goebel wrote:
Michael Schwern's AnyLoader is a bit strange though. To use an explicitly
qualified function if the only perceivable gain were to allow you to skip
needing an 'use'. After all, if the purpose is to mangle your namespace...
why are you explicitly calling a function in the first place? But that
isn't the main reason for AnyLoader is it?
The main use of AnyLoader was to automate the lazy loading of modules
on demand without the problems of autouse.pm.
$ perl -wle 'use autouse "Carp" = qw(carp croak); carp("foo")'
Subroutine carp redefined at /usr/lib/perl5/5.6/autouse.pm line 57.
foo at -e line 1
$ perl -wle 'use AnyLoader; Carp::carp("foo")'
foo at -e line 1
The main use is for branches of code which are rarely executed, yet
required pulling in heavy modules. Carp, for example (before it went
on a diet in 5.6.0).
if( $some_error ) {
require Carp;
Carp::croak("A!");
}
I got tired of writing "require Carp" all over my code.
Anyhow, the fully-qualified function name requirement can easily be
removed. All I have to do is check to see if the namespace of the
called function matches the namespace of the caller. That indicates
an unqualified, undefined function call (though doesn't guarantee it,
but this IS a prototype). Then AnyLoader looks in a (as yet
undetermined) function registry (a glorified hash), loads the
appropriate module and exports the appropriate function.
PS Actually, it REALLY exists because Arnar came up with a neat trick
and I ran with it.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
The eye opening delightful morning taste of expired cheese bits in sour milk!
