J. David Blackstone wrote:
That's one nice thing about Perl; you can foreach over
an array of all sorts of different things. In fact, being able to
just have an array of all sorts of different things is something Perl
still has over Java, C, and the like.
It's not that big a deal
Nathan Torkington wrote:
I'd rather not revisit this, or any other, RFC until Larry's had a
chance to *really* comment and put forward his suggestions.
I think pitching renames for "local" is at least as worthwhile as
pitching code names. How about "Hold?" It isn't listed in
I'd be all for the XML documentation idea, either as a replacement
for or as a substitute for POD. However, I'd like to note that if you
want XML documentation in your Perl code, POD really makes it easy:
=for XML (or DocBook, or whatever)
Simply require yourself to use only POD sections
Perl6 RFC Librarian writes:
The chief instance where Perl5 requires dynamic variables is in the
case of package globals.
I think this is a bad idea (so I'm glad you made it optional).
Thanks for the feedback, Nat.
I figured the idea would meet with resistance. Really, since the
whole
[EMAIL PROTECTED] (Nathan Wiger) wrote on 14.08.00 in
[EMAIL PROTECTED]:
Well, lexical variables don't belong to any package in Perl. They're not
in the symbol table, hence why others can't mess with them. That's why a
"my $var" is different from a "$pkg::var". The latter gets in the
I was just sitting here thinking over all these issues and making
various responses (as well as adjustments to my mental model for RFC
106 v2).
With the radical proposal of eliminating dynamic variables that RFC
106 includes (as an option! Don't get excited; read the RFC first!),
I've
Here's a radical thought:
In most languages, dynamic scoping of variables offers no advantages
over lexical scoping, other than dynamic assignment. Dynamic
assignment can be accomplished with the local() operator (soon to be
renamed, I hope). The local() operator can be extended to operate
=head1 TITLE
Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: perl6-language-strict
Number:
=head1 ABSTRACT
Perl
Is Perl currently using different epochs on different platforms? If so, I
Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
reason
On 14 Aug 2000, Russ Allbery wrote:
Day resolution is insufficient for most purposes in all the Perl scripts
I've worked on. I practically never need sub-second precision; I almost
always need precision better than one day.
MJD allows fractional days (otherwise it would of course be
Since no one else has taken this up, I'll start an initial draft.
=head1 TITLE
Rename the Clocal operator
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 4 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: not yet assigned
=head1 ABSTRACT
ople would probably want
those on by default, but I consider each piece of strictness to be a
separate issue. I can also keep up with only so many discussions and
RFCs at once. :)
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 1 A
Peter Scott wrote:
I'll say up front that I have no good idea as to how to implement this,
hence the lack of RFC, but I think it's worth getting the ball rolling to
see if there's enough collective intelligence and inclination to make
something happen.
OO inheritance is well defined and
Before jumping in on this, keep in mind that Larry Wall has already
stated his intent to just plain _eliminate_ many of these special
variables. Most of them suffer from the "action-at-a-distance"
problem, meaning you change something somewhere and unexpected changes
occur elsewhere.
For
14 matches
Mail list logo
