Re: RFC 78 (v1) Improved Module Versioning And Searching

[Bennett Todd]

2000-08-10-17:36:41 Graham Barr:
> And the difference is ?
> 
> $ perl -e 'warn \$main::fred::x," ",\$fred::x'
> SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.

Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
namespace where the "use" occurred, then perhaps main::whatever
could be a common, stable, global that they could use for these rare
variables that really need to be common from multiple invokers.

-Bennett

 PGP signature

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Graham Barr]

On Thu, Aug 10, 2000 at 10:43:02AM -0400, Bennett Todd wrote:
> If the only real problem that can be found with making module use
> package-local is in these few option-flag type variables, perhaps
> they could be handled differently. E.g. suppose normal package
> variables end up being local to the package that "use"-es the
> package, and when a package actually wants to make a genuine global
> for all users of the package, it explicitly tucks it into a variable
> whose name starts with main::. E.g. let Net/FTP.pm post its debug
> flag into $main::Net::FTP::Debug, and the list of exception classes
> requested of Fatal.pm could be posted into @main::Fatal.

And the difference is ?

$ perl -e 'warn \$main::fred::x," ",\$fred::x'
SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.

Graham.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Chaim Frenkel]

I'd put it into 

Perl::Option{__Package__} 

There was some talk about making Perl:: special. So that might be the one
and only truely global space.

Hmm, that wouldn't work with multiple versions without cooperation.

Alternatively, we could treat a set 

Perl::Option{FTP::Net}->Debug = 255;

as a method call, and have the package determine it's caller.



> "BT" == Bennett Todd <[EMAIL PROTECTED]> writes:

BT> If the only real problem that can be found with making module use
BT> package-local is in these few option-flag type variables, perhaps
BT> they could be handled differently. E.g. suppose normal package
BT> variables end up being local to the package that "use"-es the
BT> package, and when a package actually wants to make a genuine global
BT> for all users of the package, it explicitly tucks it into a variable
BT> whose name starts with main::. E.g. let Net/FTP.pm post its debug
BT> flag into $main::Net::FTP::Debug, and the list of exception classes
BT> requested of Fatal.pm could be posted into @main::Fatal.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Steve Simmons]

> Perhaps Damian's want() (RFC 21) can be used to allow allow either return
> type? 

Yes indeed.

> Assuming that's adopted, of course.

Sure looks to me like a good idea; I hope it does.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 05:46 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> > No, it wouldn't, really. We could make "use fatal;" scoped, so that the
> > quit op (or whatever it is) only jumps through all its hoops if the
> > pragma's in effect. If its not, then quit(foo, bar, baz) does a bare 
> return
> > and that's it.
> >
> > You'd have the overhead of checking a flag when actually quitting with an
> > error, but that adds a very small amount of overhead to an exceptional 
> case.
>
>Why not make that flag avaliable instead of having a new op ?
>
>The user can then write
>
>   $^fatal ? die  : return;

Sure, that works. Whatever keyword throws the non-fatal error might just be 
a perl sub that does exactly that, at least to start. (Maybe always, who knows)

>Hm, although people may start to mis-use the flag.

What, people misuse core functionality? I can't picture *that* happening. 
It's so unperlish... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Graham Barr]

On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> No, it wouldn't, really. We could make "use fatal;" scoped, so that the 
> quit op (or whatever it is) only jumps through all its hoops if the 
> pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return 
> and that's it.
> 
> You'd have the overhead of checking a flag when actually quitting with an 
> error, but that adds a very small amount of overhead to an exceptional case.

Why not make that flag avaliable instead of having a new op ?

The user can then write

  $^fatal ? die  : return;

Hm, although people may start to mis-use the flag.

Graham.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 12:11 PM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-11:52:31 Dan Sugalski:
> > Why not, then, introduce non-fatal errors and a new keyword to
> > throw them?
>
>Arranging for all the builtins to throw a non-fatal exception would
>impose a cost on the rest of the folks, who prefer to have most
>errors ignored (the way perl currently works), but who want to just
>check for the error return from select calls: they would have to do
>things differently.

No, it wouldn't, really. We could make "use fatal;" scoped, so that the 
quit op (or whatever it is) only jumps through all its hoops if the 
pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return 
and that's it.

You'd have the overhead of checking a flag when actually quitting with an 
error, but that adds a very small amount of overhead to an exceptional case.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Bennett Todd]

2000-08-10-11:52:31 Dan Sugalski:
> Why not, then, introduce non-fatal errors and a new keyword to
> throw them?

If we were to add a non-fatal exception type, that would just mean
that those of us who want errors to behave differently than they do
now, would have to wrap our whole program in a catcher; that's just
a couple of extra lines of clutter, and I'm sure they could be
deposited in a module to reduce it back to the desired one line.

Arranging for all the builtins to throw a non-fatal exception would
impose a cost on the rest of the folks, who prefer to have most
errors ignored (the way perl currently works), but who want to just
check for the error return from select calls: they would have to do
things differently.

Your suggestion (all builtins through non-fatal exceptions for error
reporting) would make implementing Fatal.pm a lot easier, but a less
intrusive measure (making all error-reporting buitins wrappable, my
RFC 70) would at least make Fatal.pm possible to implement
completely, and would inflict little or no change on the people who
like perl's currently style of error reporting.

But I do see one worry about the proposed non-fatal exception type,
and that is that it would require some interesting implementation
hair to make it work; unlike the current exceptions, non-fatals
would require passing state downward, and defining its scope,
because the routine throwing an exception has to know whether
they're being caught before it actually throws. Or else we'd have
to have continuations, and the non-fatal exception could be thrown
with a continuation, which a default catcher could use to resume
execution ignoring the error. I can't believe I suggested that.

-Bennett

 PGP signature

RE: RFC 78 (v1) Improved Module Versioning And Searching

[Brust, Corwin]

-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]

> For the record, I prefer hashes for that sort of thing too.  But
> perl has traditionally done ordered list returns, and I followed in
> that vein.

Perhaps Damian's want() (RFC 21) can be used to allow allow either return
type? 

Assuming that's adopted, of course.

-Corwin

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Simply Hao]

You might want to check out Umbrella Frameworks:

  http://arstechnica.com/reviews/2q00/macos-x-dp4/macos-x-dp4-3.html

It would be good for some of us to have an easier way of using
multiple versions of modules sometimes.

-Hao

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 10:43 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-09-21:00:31 Chaim Frenkel:
> > Making a module local to the using package, might have interesting
> > properties. [...]
> > The only breakage that I see, is having some way of globally setting
> > a variable. For example, turning on debugging for all uses. (FTP::Debug
> > I find quite popular.)
> >
> > Can anyone see any other breakage?
>
>Not other breakage, but another example of the same exact class
>of breakage. In RFC 70 I proposed some (hopefully minor) language
>cleanups to make it possible to have Fatal.pm actually work the
>way people want it. If it worked, then Fatal.pm would be getting
>some categories it supported, e.g. "use Fatal qw(:io);". I then
>suggested that the invoked categories could be posted into a
>testable variable, in case other module authors wished to cooperate
>with this protocol.

Why not, then, introduce non-fatal errors and a new keyword to throw them? 
Something like quit(), which could take an error class, an error identifier 
(a number or short string or something) and a message. It'd work like a 
bare return, but also stick something in $@, and could be trappable. (Quit 
with one parameter would default the class to generic, and the identifier 
to unknown)

This way, when something needs to bail with a non-fatal error it could:

   quit('io', 'READERROR', "Unable to read from file $foo");

and the code calling the sub could, if it wanted, could do a plain:

   $foo = some_sub($file);

or:

   {
 use fatal;
 eval {
   $foo = some_sub($file);
 };
 if ($@) {
   if ($@->nonfatal) {
 # handle non-fatal errors
   }
 }
   }

or something like that.

*) Define a set of c

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Steve Simmons]

On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote:

> Rather than proliferating the number of keywords eaten with all
> these *ref varients, this sounds like a useful place for returning
> an object with a default stringification of the class:
>  . . .
> Ref RFC 37, RFC 73.

I have no problem with this or any other solution that gets the
data back.  I'll add a comment to RFC78 that should those RFCs
prevail, we'll follow them.

For the record, I prefer hashes for that sort of thing too.  But
perl has traditionally done ordered list returns, and I followed in
that vein.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Ted Ashton]

Thus it was written in the epistle of Steve Simmons,
> On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:
> 
> > I'll take that as my cue ;-).
> 
> Ah, nothing like a man who knows when to pick up his cues.

:-)

> > <*shudder*>  This whole business is getting pretty scary . . .
>   [[ discussion of ugly implicatations elided ]]
> 
> The short answer is that (assuming I understand Larry's statement)
> he'd like these issues addressed.  If the resulting `best' answer
> is so complex and so ugly that he decides it's a bad idea, that's
> fine -- but (if I recall correctly) tcl has addressed this problem
> and come up with workable solutions.  I'm not intimately familiar
> with them, but will get so.

Understood.  After a bit of reflection on it, I got to wondering, what if it
  1) Searched all of @INC for the most recent module which fits within the 
 constraints given (version range numbers, at least).
  2) Loaded the module globally (as it does now) *unless* told not to.  Thus,
 if a module wanted to
   use Foo private;
 then it could.
As far as the author business goes, is it becoming unwieldy to have portions
of the namespace assigned to specific authors?  That is, Devel::SmallProf is 
mine (as per committee decision) and others wanting to write small profilers
can have TinyProf, MicroProf and so forth.  I really think that multiple 
versions of a module are a fairly natural thing, but that modules with the
same name by different folks are bound to cause confusion, much beyond the 
actual running of programs.  

  PerlUserA:  I keep having this problem with the Foo::Bar module.  It won't
grok blargs as it ought.
  PerlUserB:  You must be doing something wrong.  It works fine for me.
<*three day conversation ensues*>
  PerlUserB:  I give up.  I don't know what you're doing wrong.  Why don't you
write to Tom and ask him.
  PerlUserA:  Tom, why Tom?
  PerlUserB:  Because he wrote the module.
  PerlUserA:  No he didn't.  Ilya wrote it.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is not knowledge, but the act of learning, not possession but the act of
getting there, which grants the greatest enjoyment. When I have clarified
and exhausted a subject, then I turn away from it, in order to go into
darkness again; the never-satisfied man is so strange if he has completed a
structure, then it is not in order to dwell in it peacefully, but in order
to begin another. I imagine the world conqueror must feel thus, who, after
one kingdom is scarcely conquered, stretches out his arms for others.
   -- Gauss, Karl Friedrich (1777-1855)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Steve Simmons]

On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:

> I'll take that as my cue ;-).

Ah, nothing like a man who knows when to pick up his cues.

> <*shudder*>  This whole business is getting pretty scary . . .
  [[ discussion of ugly implicatations elided ]]

The short answer is that (assuming I understand Larry's statement)
he'd like these issues addressed.  If the resulting `best' answer
is so complex and so ugly that he decides it's a bad idea, that's
fine -- but (if I recall correctly) tcl has addressed this problem
and come up with workable solutions.  I'm not intimately familiar
with them, but will get so.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Bennett Todd]

2000-08-09-17:33:25 Steve Simmons:
> If that's the intent, then yes, author name must become part of the
> package identifier.  Rather than change the meaning of "ref $object"
> unexpectedly, I'd add one or more alternate forms of ref.  Off the
> top of the head, something like
> 
> ( $version, $class ) = vref $object;  # ref with version
> ( $author, $class ) = aref $object;   # ref with author
> ( $version, $author, $class ) = fref $object;   # get all

Rather than proliferating the number of keywords eaten with all
these *ref varients, this sounds like a useful place for returning
an object with a default stringification of the class:

$class = ref $object; # when you use $class as a string,
  # or 2nd arg to bless()
$version = $class->{VERSION};
$author = $class->{AUTHOR};

Ref RFC 37, RFC 73.

-Bennett

 PGP signature

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Bennett Todd]

2000-08-09-21:00:31 Chaim Frenkel:
> Making a module local to the using package, might have interesting
> properties. [...]
> The only breakage that I see, is having some way of globally setting
> a variable. For example, turning on debugging for all uses. (FTP::Debug
> I find quite popular.)
> 
> Can anyone see any other breakage? 

Not other breakage, but another example of the same exact class
of breakage. In RFC 70 I proposed some (hopefully minor) language
cleanups to make it possible to have Fatal.pm actually work the
way people want it. If it worked, then Fatal.pm would be getting
some categories it supported, e.g. "use Fatal qw(:io);". I then
suggested that the invoked categories could be posted into a
testable variable, in case other module authors wished to cooperate
with this protocol.

If the only real problem that can be found with making module use
package-local is in these few option-flag type variables, perhaps
they could be handled differently. E.g. suppose normal package
variables end up being local to the package that "use"-es the
package, and when a package actually wants to make a genuine global
for all users of the package, it explicitly tucks it into a variable
whose name starts with main::. E.g. let Net/FTP.pm post its debug
flag into $main::Net::FTP::Debug, and the list of exception classes
requested of Fatal.pm could be posted into @main::Fatal.

The next natural thought seems to be that the module creating such
a global should check and see if it's being used by main, and
only post into the global if so, otherwise let its option[s] be
user-local. Can import() use caller() this way? That would allow
a module author to e.g. code their module using Fatal, without
affecting anything outside their module, while allowing main's
invocation (if any) of Fatal to offer guidance to other modules that
chose to try and honor it.

-Bennett

 PGP signature

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Chaim Frenkel]

Let's not throw this out completely. Let's explore the possiblities.

Making a module local to the using package, might have interesting
properties.

The only items of interest are the globals. And by making them visible
(or a version visible) to the use-ing module, two modules can get
different behaviours without stomping on each other.

All the isolation that we're developing for threads would help this out.

So the used package's globals can be lexically scoped in the user.

The only breakage that I see, is having some way of globally setting
a variable. For example, turning on debugging for all uses. (FTP::Debug
I find quite popular.)

Can anyone see any other breakage? 



> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

DS> It'll happen at least once.

DS> I suppose we could go insane and make packages loaded in through modules 
DS> completely invisible to all but the use-ing package, so in this case main 
DS> wouldn't even know there was a C loaded, and if it tries to mess with 
DS> things in the C package it gets its own empty stash to deal with. (Which 
DS> all other packages that didn't use one version of the module or another get)

DS> I suppose that's a fancy way of saying namespaces created by used modules 
DS> are private to the package using them. (Though that still leaves the issue 
DS> of what happens when package B uses something from package C which wasn't 
DS> created on the use, but then I'd probably just say "you get your version of 
DS> C. Nyah!")


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Bart Lateur]

On 9 Aug 2000 15:03:40 -, Perl6 RFC Librarian wrote:

>Improved Module Versioning And Searching

[About loading different versions of a module at the same time]

The whole thing sounds whacky to me.

I don't really mind that @INC is searched for the most recent version of
a module, but otherwise, my solution would be simple: authors that don't
provide complete backward compatibility with older versions of the same
module, safe the bugs, and safe beta versions, should be kicked of CPAN.

 ;-)

(I wouldn't dare...)

-- 
Bart.

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Ted Ashton]

Thus it was written in the epistle of Steve Simmons,
>
> >  . . . but I already promised the CPAN
> > workers that I'd make that last statement false.  There's no reason in
> > principle why two modules shouldn't be allowed to have their own view
> > of reality.  Just because you write Foo::bar in your module doesn't mean
> > that Perl can't know which version of Foo:: you mean.
> 
> OK, let's let someone else get into the conversation.

I'll take that as my cue ;-).

> DS> . . . If you use C in package A, and also in package B, which do you
> DS> see when you're in main and access $C::bar?
> 
> LW> I dunno.  I don't imagine the situation will arise that often.
> 
> It may not happen often, but once is enough.  IMHO the answer is `in load
> order' unless the programmer does something explicit to resolve the
> issue.

<*shudder*>  This whole business is getting pretty scary.  Best that I can 
tell, what y'all are saying is that if A and B happen to both load the same
version of C, then A can say $C::flag = 1 and B can see that, but if they 
load differing versions, then they can't (as there are two copies of $C::flag).
Oi!  If you are going to split it up in that fashion, I would think that you
would have to go all the way.  No matter what version is available, every
load of a package from another package is private to that package.  A has it's
mirage of C and B has it's mirage of C, even if they loaded the same version,
and main has no access to either.

I happen to have a profiler out there which uses the DB package.  What happens
if someone loads SmallProf and DProf and the perl debugger all at once?

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
Mathematics is not only real, but it is the only reality. That is that
entire universe is made of matter, obviously. And matter is made of
particles. It's made of electrons and neutrons and protons. So the entire
universe is made out of particles. Now what are the particles made out of?
They're not made out of anything. The only thing you can say about the
reality of an electron is to cite its mathematical properties. So there's a
sense in which matter has completely dissolved and what is left is just a
mathematical structure.
   -- Gardner, Martin
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 01:50 PM 8/9/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 11:11 AM 8/9/00 -0700, Larry Wall wrote:
>: >Dan Sugalski writes:
>: >: Does that mean, then, that when module A does a "$C::bar = 1" it 
>affects a
>: >: different package namespace than module B doing a "$C::bar = 2"?
>: >
>: >Presumably.
>:
>: H. That brings up some issues of ambiguity, then. If you use C in
>: package A, and also in package B, which do you see when you're in main and
>: access $C::bar?
>
>I dunno.  I don't imagine the situation will arise that often.

It'll happen at least once.

I suppose we could go insane and make packages loaded in through modules 
completely invisible to all but the use-ing package, so in this case main 
wouldn't even know there was a C loaded, and if it tries to mess with 
things in the C package it gets its own empty stash to deal with. (Which 
all other packages that didn't use one version of the module or another get)

I suppose that's a fancy way of saying namespaces created by used modules 
are private to the package using them. (Though that still leaves the issue 
of what happens when package B uses something from package C which wasn't 
created on the use, but then I'd probably just say "you get your version of 
C. Nyah!")

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Steve Simmons]

On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote:

> : Note that it may not be possible to satisfy conflicting requests.  If
> : module C and module C demand two different versions of the same
> : module C, the compiler should halt and state the module conflicts.
>
> Pardon me for sniping at a great RFC . . .

No problem, I don't feel sniped at.

>  . . . but I already promised the CPAN
> workers that I'd make that last statement false.  There's no reason in
> principle why two modules shouldn't be allowed to have their own view
> of reality.  Just because you write Foo::bar in your module doesn't mean
> that Perl can't know which version of Foo:: you mean.

Near the end of the RFC this topic does come up; see it directly at
.
That section was much longer in my unreleased drafts, but did include
some discussion on disambiguation when multiple versions of the same
module are loaded.  In the RFC I wrote off this idea with ``In This Way
Lies Madness, but perl has done stranger things.''

If we want to open that can of worms I'm willing to pitch in.  I'll even
continue on with the task of maintaining the RFC, or starting another
if appropriate.  But I'd barely started thinking about this issue with
respect to perl until a couple of days ago, so folks who are much more up
to speed on language/inheritence/etc are going to have to carry the load.

Turning back to some specific comments made by Larry and by Dan Sugalski:

LW> The larger view of it is how to support package aliasing.  A package
LW> name is essentially the name of a public interface.  Suppose you
LW> have one interface, but two or more different implementations of
LW> that interface by different people.  Each might have their own
LW> version sequence.

Package aliasing should certianly be allowed; the RFC already contains
a suggestion for it:

use foo <3.0 as foo_old;
use foo =3.0. as foo;
use foo >3.0. as new_foo;

Using the alias gets you what you need.

Your comment above implies that CPAN may (will be allowed to) contain
modules of the same name and same version by different authors.  Is this
correct?  If so (shudder), what happens currently when both are installed?
I presume one simply overwrites some or all of the other.

If that's the intent, then yes, author name must become part of the
package identifier.  Rather than change the meaning of "ref $object"
unexpectedly, I'd add one or more alternate forms of ref.  Off the
top of the head, something like

( $version, $class ) = vref $object;  # ref with version
$version = vref $object;  # scalar context gets version
( $author, $class ) = aref $object;   # ref with author
$author = aref $object;   # scalar context gets author
( $version, $author, $class ) = fref $object;   # get all
# Scalar context gets a string suitable for select the
# exact object in use
$fq_name = fref $object;

if ( $fqname eq fref $other_object )...

LW> Another question is whether the two different versions of the "same"
LW> module are going to stomp on each other?  (Not in package space, since
LW> the packages are distinguished internally, but how about in the
LW> filesystem?)

If we include author name along with the version number in the file system
namespace (gawd, I can't believe I just wrote that), then clobbering
won't happen.  IMHO this feature is no more difficult to add to the
install process than adding version numbers; it implies tho that we
need a $AUTHOR var in all modules and to allow for it in module `version'
specifications.  Again, off the top of the head, we could allow a string
(any string that would not be confused with a version number) to indicate
the author:

use foo CONWAY <=1.3  as foo_good;
use foo GATES   >1.3  as foo_bad;
use foo * as foo_desperate;

As long as there's no author names `as', we're cool.  I suspect the
proposed syntax in the RFC could be extended to handle this unambiguously
both for run/compile-time module naming and for installation, but need
to think it thru.

DS> Does that mean, then, that when module A does a "$C::bar = 1" it
DS> affects a different package namespace than module B doing a
DS> "$C::bar = 2"?

LW> Presumably.

Yes, that's how I'd see it too.  Which creates a real problem for
modules which do things like

package foo;

{
my $hidden_var;

sub new {
if ( $hidden_var ) {
do x;
} else {
do y;
}
}
}

Now there are two copies of $hidden_var while the module clearly expects
only one.  Either this kind of construction will have to be avoided,
or some mechanism developed which allows multiple version of a module
to somehow share important data which is otherwise hidden by such tricks.

IMHO, module authors should be able to forbid multi-loads across
sufficiently different versions

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

Dan Sugalski writes:
: At 11:11 AM 8/9/00 -0700, Larry Wall wrote:
: >Dan Sugalski writes:
: >: Does that mean, then, that when module A does a "$C::bar = 1" it affects a
: >: different package namespace than module B doing a "$C::bar = 2"?
: >
: >Presumably.
: 
: H. That brings up some issues of ambiguity, then. If you use C in 
: package A, and also in package B, which do you see when you're in main and 
: access $C::bar?

I dunno.  I don't imagine the situation will arise that often.

: >Think about the long names of fonts for an example of how far this
: >can be taken.
: 
: Would this be "Taken to its logical and sensible conclusion" or "Taken as 
: far as it can possibly go, though it you turn around and look *really* hard 
: with binoculars you can see where you crossed the line, way back there by 
: the horizon"?

I was leaving that one ambiguous on purpose.  :-)

Larry

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 11:11 AM 8/9/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Does that mean, then, that when module A does a "$C::bar = 1" it affects a
>: different package namespace than module B doing a "$C::bar = 2"?
>
>Presumably.

H. That brings up some issues of ambiguity, then. If you use C in 
package A, and also in package B, which do you see when you're in main and 
access $C::bar?

>: And does it also extend to things like this:
>:
>: package A;
>: use C 1.2;
>: package B;
>: use C 1.4;
>:
>: where two packages in the same file use different versions of module C and
>: get them?
>
>I expect that could also be made to work, provided the semantics of
>importation remain package-scoped and don't become lexically scoped.

Sure. They'd have to be, otherwise packages split across different files 
would get a rather bizarre view of the world. This sort of means we'll need 
some sort of two-level stash, one per-package and one global. (Unless 
you're outlawing symbolic references... :)

>To me, it really just means that the *real* name of the package includes
>the implementation (author?) and version, but that when you say
>
> use C;
>
>you're just choosing to wildcard both the implementation and version.
>This view says that we probably ought to figure out how to encode the
>implementation and version syntactically as part of the package name,
>rather than as a 3rd argument to use.

Yup. I can see the build procedures needing to know this too, since we'll 
probably need to give modules with shared libraries unique names. Some 
platforms (OS/2 and VMS, at least) will need that, as they get cranky if 
you try and load shareables with the same base filename.

>Think about the long names of fonts for an example of how far this
>can be taken.

Would this be "Taken to its logical and sensible conclusion" or "Taken as 
far as it can possibly go, though it you turn around and look *really* hard 
with binoculars you can see where you crossed the line, way back there by 
the horizon"?

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

Dan Sugalski writes:
: Does that mean, then, that when module A does a "$C::bar = 1" it affects a 
: different package namespace than module B doing a "$C::bar = 2"?

Presumably.

: And does it also extend to things like this:
: 
: package A;
: use C 1.2;
: package B;
: use C 1.4;
: 
: where two packages in the same file use different versions of module C and 
: get them?

I expect that could also be made to work, provided the semantics of
importation remain package-scoped and don't become lexically scoped.

To me, it really just means that the *real* name of the package includes
the implementation (author?) and version, but that when you say

use C;

you're just choosing to wildcard both the implementation and version.
This view says that we probably ought to figure out how to encode the
implementation and version syntactically as part of the package name,
rather than as a 3rd argument to use.

Think about the long names of fonts for an example of how far this
can be taken.

Larry

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 10:44 AM 8/9/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: Note that it may not be possible to satisfy conflicting requests.  If
>: module C and module C demand two different versions of the same
>: module C, the compiler should halt and state the module conflicts.
>
>Pardon me for sniping at a great RFC, but I already promised the CPAN
>workers that I'd make that last statement false.  There's no reason in
>principle why two modules shouldn't be allowed to have their own view
>of reality.  Just because you write Foo::bar in your module doesn't mean
>that Perl can't know which version of Foo:: you mean.

Does that mean, then, that when module A does a "$C::bar = 1" it affects a 
different package namespace than module B doing a "$C::bar = 2"? And does 
it also extend to things like this:

package A;
use C 1.2;
package B;
use C 1.4;

where two packages in the same file use different versions of module C and 
get them?

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

[EMAIL PROTECTED] writes:
: Note that it may not be possible to satisfy conflicting requests.  If
: module C and module C demand two different versions of the same
: module C, the compiler should halt and state the module conflicts.

Pardon me for sniping at a great RFC, but I already promised the CPAN
workers that I'd make that last statement false.  There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality.  Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.

The issue is actually more general than just versioning.  The larger
view of it is how to support package aliasing.  A package name is
essentially the name of a public interface.  Suppose you have one
interface, but two or more different implementations of that interface
by different people.  Each might have their own version sequence.

There are open questions on that, of course.  If we have two different
packages of the same name differentiated only by version or by author
(or both), we obviously count that internally as part of the name of
the package.  To what extent do we need to reveal the full internal
name of a package?  (For instance, does the author/version show up as
part of the name when you say "ref $object".)

Another question is whether the two different versions of the "same"
module are going to stomp on each other?  (Not in package space, since
the packages are distinguished internally, but how about in the
filesystem?)

There are also policy issues with package naming.  When and how do we
declare that a package name like XML::DOM is a standard abstract
interface that belongs to no one implementation, and restrict version
numbers to interface revisions, not implementation revisions?

Basically, there are some more things we have to think about if we
really want to do Best Fit rather than First Fit.  And I think we do.

Larry