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
names
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 t
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}->
> 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.
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
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'
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 mo
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 ca
-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 ret
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
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
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 p
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 . . .
> [[ di
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 (ass
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
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.)
>
>
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 b
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 otherwi
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
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"?
>: >
>
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 snipin
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
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
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;
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
[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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Improved Module Versioning And Searching
=head1 VERSION
Maintainer: Steve Simmons <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 78
CVSID: $Id: modules.p
27 matches
Mail list logo
