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')
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:
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
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'.
>: 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.
Nope, I wasn't. I was using the word "source" where you were saying
> 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 one with a last name starting with "ADA", I can't say I've noticed
any problems with alphabetical. =).
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:
>: 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.
metamodule. hmm. That brings us back to Aaron Sherman's topic of
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:
module Dog-1.2.5-AdamsR is Stable;
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
>: By saying
>: 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:
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