On Wed, Nov 10, 2004 at 01:12:46PM -0600, Rod Adams wrote:
: 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?
I don't think so--those have to interact with a dispatcher in addition
to ordinary name lookup. But maybe AUTOVAR should be split up by
variable type. The whole autoloading design is still pretty handwavy.
: 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
: 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.
You don't have to convince me of that. I've already put in aliasing
so we can have short names for versioned modules. We just need to
give the user a little more control of the actual aliasing.
: As one with a last name starting with "ADA", I can't say I've noticed
: any problems with alphabetical. =).
We could go with reverse alphabetical. :P
: As for picking "randomly", I think a more deterministic method would be
: in order.
Sorry, I should have put another smiley on that, but I was running low...
: 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).
Though bear in mind that we're totally restructuring how libraries work
so that we can have a given module visible to multiple versions of perl
by default. Rather than probing directories directly, we're probably searching
some kind of stupid databasish thing. (But that stupid databasish thing
may well be built or selected based on your current @INC settings, since
we do have be able to let people have local policy somehow or other.)
: 2b) else, pick the one with the lowest CRC32 value of the Author
The problem with that is that people will intentionally sign up for
author ids that have low hashed values. I'd rather say that we die
on ambiguity, but ambiguity can be resolved by one module claiming
it's better than the other, so there's a partial ordering available
via the metadata. One would have to die on partial ordering loops,
of course. Probably we detect any such loop at installation time in
the main library, and in fact we could detect ties at that point and
make the installer pick who should win.
: metamodule. hmm. That brings us back to Aaron Sherman's topic of
: re-exportation.
: 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?
Maybe it's just
module MyPolicy is meta {
use strict;
use warnings;
use fatal;
}
or
module MyPolicy {
meta strict;
meta warnings;
meta fatal;
}
or some such.
: So one could make a call such as:
:
: Dog.pm:
:
: module Dog-1.2.5-AdamsR is Stable;
:
: ...
:
:
: main.pl:
:
: use Dog is Stable;
That would only work if "is" bound to the class name, which is a bit odd.
The current "use" syntax is pretty general, but it doesn't map well to
Perl 6 declaration syntax.
: 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.
But note that you're assuming with that last one that /usr/bin/perl
isn't the current Perl 5 interpreter. I'm not sure that's a valid
assumption any time soon.
: 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.
Well, for sure you'll end up on back on the ponie if you feed a
"use 5" to perl6.
Larry
