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.

: How does one create a class with a hyphen in the middle of it?

Why would you want to?  Perl 5 doesn't allow it, and I sincerely doubt
Parrot is going to incorporate a bunch of Lisp libraries any time soon.

; If I say:
: 
: use Foo-Bar;
: 
: will it complain about not finding a Bar version of Foo?

It'd probably complain that Bar doesn't look anything like a version number.

: Would I instead need to say:
: 
: use 'Foo-Bar';
: use Foo\-Bar;
: use ('Foo-Bar');
: $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')

: If we do:
: 
: 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.

: 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.  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.

: 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.  (And placeholders only work inside
closures.)

: 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.

: Can we get a hook that gets called when 'use' fails to find module 
: locally? I see potential for:
: 
: use AutoCPAN;
: use Some::Module::Not::Currently::Loaded;
: 
: hmm. that doesn't work, since you typically won't be including the cpan 
: author code if you don't have to.

Perl 6 will give you enough rope to shoot yourself in the foot.

: CPAN, or some other public source would be a definate security risk, and 
: thus to be discouraged, but it should be possible to write the thing. 
: I've heard of sites who had massively distributed mod_perl servers, 
: where all the code past a simple stub was stored in a central RDBMS. 
: Made releases and version control much nicer.

All is fair if you predeclare.

: 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.

Which is perhaps another argument for finding a different keyword than "use".

Larry

Reply via email to