Larry Wall wrote:
On Tue, Nov 09, 2004 at 09:18:47PM -0600, Rod Adams wrote: : Can we get an AUTOCLASS/AUTOCLASSDEF hook pair?
Considering a class is just a variable in another symbol table, seems
like an AUTOVAR in the container might cover it.
I guess I don't understand enough of how P6 is being built, but wouldn't a similar argument hold for AUTOMETH and AUTOSUB?
: $x = 'Foo-Bar'; use $x;
: : btw, that last one would be really handy sometimes, but for other reasons.
All symbolic indirection is done with ::($expr) in Perl 6, so it'd be
use ::('Foo-Bar')
Very nice.
: If we do:I'm largely indifferent to the exact syntax involved, as long as I have some way to loading two different versions of the same module, and can then differentiate between them in my code. Possible reasons for loading two versions of the same thing:
: : use Dog-1.2.3;
: use Dog-2.0.1;
: my Dog $spot;
: : What do we get? Okay, I know, an error message, but is it on line 2 or : line 3?
Presuming we add some way to do aliasing, line 2 would give an error.
: Can we instead do something like:
: : use Dog-1.2.3;
: use Dog-2.0.1 is rename(newDog);
: my newDog $spot;
More likely something on the order of
module newDog ::= (use Dog-2.0.1);
where it's only a "use" in a void context that implicitly uses the same short name as the alias. But like I said, it's not even clear that the pseudo listop syntax of "use" is the right way to handle this. Maybe it's just an "isa"-like thing:
my module newDog is Dog-2.0.1;
or maybe it's more like a role:
my module newDog does Dog-2.0.1;
But maybe it's something else again that we just haven't thought of yet.
1) Retrograde testing. You just built a new version, and you want to have the two versions running side by side through the test cases, without having to kick off a new instance.
2) The nifty new version has a whiz-bang function you really need, but in the process of upgrading, it broke some other whiz-bang function.
3) The two really are not the same thing, they were just given the same name.
There are some separate benefits of module aliasing, aside from loading like-named modules, to consider:
1) The module is named something like "AudioFile::Info::Ogg::Vorbis::Header::PurePerl", and you'd rather not type it more than once.
2) You just changed your entire module naming scheme, and want a stop gap measure for all you code that's still referring to the old names.
: There needs to be some definition of what happens when more than one : module matches a given wildcard in 'use'.Nope, I wasn't. I was using the word "source" where you were saying "author".
: : Something like:
: 1. Throw a warning
: 2. Pick the highest version, then the earliest source in the alphabet
I think you're assuming version numbers contain alphabetics. I'd like to stay away from that if possible.
As one with a last name starting with "ADA", I can't say I've noticed any problems with alphabetical. =).But I think #2 is far and away the most common intent with a wildcard on version numbers. I don't know what the pecking order should be among authors, but as someone who has suffered from being a W, it's not going to be alphabetical. :-)
My wife didn't believe me till she married me and moved from B to W.
Maybe #1 is a suitable response for multiple matching authors. Or maybe
it should just pick one randomly to keep people honest.
As for picking "randomly", I think a more deterministic method would be in order. But something that can't be easily abused by naming it "____0000AAAA". How about the following rules for multiple wildcard matches:
1) If the version numbers differ, pick the highest.
2) else, throw a warning (error if strictures), AND
2a) if one is in a directory earlier in @INC than the other(s), use it. (Allow users to have a local copy override a global one).
2b) else, pick the one with the lowest CRC32 value of the Author
: of course, there should be a way to flag it to work in other ways, so : some project could have a standard:metamodule. hmm. That brings us back to Aaron Sherman's topic of re-exportation.
: : use ($^name ~~ /^Project::/)-(Any)-TPFBundle;
: : meant to include all the modules made thus far. And yes, I can come up : with times when this would be useful.
That sort of thing should be hidden in a metamodule. In any event, it doesn't give a good name to alias to.
How does one make a metamodule which uses other modules, and has those modules' exports available to metamodule's caller, as if the caller had instead called all of those modules in addition to the metamodule?
(And placeholders only work inside closures.)Grr. My web browser used a font that does not adequately distinguish between braces and parens, so I didn't see the difference when reading it.
: I see some utility in having an optional sub-source or version code thingy.
: Something like:
: : use Dog-(Any)-(Any)-Stable;
: use Canine-(Any)-(Any)-Development;
Doesn't seem like a strong case to me. At some point we transition to
ordinary adverbials to specify optional metadata.
So one could make a call such as:
Dog.pm:
module Dog-1.2.5-AdamsR is Stable;
...
main.pl:
use Dog is Stable;
I can't say I've been able to keep all the is/but/has/: in my head for any duration. It always makes sense when I study it, but without use it fades.
: By saying
: : #!/usr/bin/perl6
: : forces Perl 6, I assume you mean : "The compiler sees /:i ^#! .* perl6/ : on the first line".
Yes. But that presumes anything wanting to run ponie doesn't invoke
it by feeding Perl 5 code to /usr/bin/perl6. Presuming /usr/bin/perl
is reserved for the current Perl 5 engine, we either have to provide
an entry like /usr/bin/ponie, or say that /usr/bin/perl6 doesn't actually
force Perl 6.
I would think
/usr/bin/perl6 forces perl6
/usr/bin/ponie forces ponie
/usr/bin/perl5p alias for ponie, as some sites might find the term "ponie" too removed from "perl"
/usr/bin/perl uses other rules to detect ponie vs perl6.
Which is perhaps another argument for finding a different keyword than "use".The easiest, of course, is "Use". But that's likely the wrong answer. The next most obvious ones are "import", "include", and "load".
playing with a thesaurus, I see:
acquire add adopt admit apply embrace employ exploit fetch grab introduce involve
But overall, I think staying with "use" is best. Giving people a ponie to play with in their transition to p6 is, I think, enough. The shebang line should provide more than enough opportunity to declare what you want, even if you have to resort to the -*- tricks to get there. We would just have to say that as far as multiple option on the shebang line goes, the latest one specified wins. (to help people on weird systems where they might have to call perl6 to get ponie.
-- Rod Adams
