Paul Seamons wrote:
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the need for all these
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I
Michael G Schwern wrote:
I think you misunderstand. This isn't named parameters vs prototyped
parameters vs args as list. The problem is the idea that functions
should accept *multiple styles by default* which the proposed
Module::Interface does.
No, it doesn't. Unfortunately, I used
Kirrily Robert wrote:
I also think there's too much overhead in learning (and remembering)
each library's quirks. My most common mistakes when using CPAN or core
modules occur when the modules have inconsistent interfaces and I forget
which ones take hashes and which take hashrefs, etc.
* Damian Conway [EMAIL PROTECTED] [06/25/2001 13:20]:
But one could also imagine that Perl 6 might allow individual objects to
have an CISA property that pre-empted their class's C@ISA array.
At some point, it is probably worth talking about Perl's ALLCAPS subs
for special methods. For
* Simon Cozens [EMAIL PROTECTED] [06/14/2001 15:16]:
OK, I've been teasing people about this for weeks, and it's time to stop.
This is the current state of the Perl 6 emulator; it applies most things
that Damian talked about in his keynote yesterday, and most of the things
I've picked up in
* Michael G Schwern [EMAIL PROTECTED] [05/18/2001 12:32]:
Let me see if I understand this...
$Foo is true;
# Meanwhile, in another part of the city...
$Foo = 0;
print My spider sense is tingling if $Foo;
Does that print or not?
Maybe there are two different features being
Dammit, I got the example exactly backwards. Try this:
$Foo is true;
$Foo = 0;
print Stuff if $Foo; # *WOULD* print - is assigns a
# permanent true property
$Foo as true = ;
$Foo = 0;
print Stuff if $Foo; # *WOULD NOT* print
* Michael G Schwern [EMAIL PROTECTED] [05/15/2001 17:49]:
Is that autochomp as a keyword or autochomp as an indirect method call
on $*ARGS?
Who cares? ;-)
The thing I worry about is this: I don't think actions should be
declared using is, necessarily.
$STDERR is flushed;
* Dave Storrs [EMAIL PROTECTED] [05/16/2001 11:25]:
I recently received the following email from someone whose name I
have snipped.
* Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]:
Ok, this is basically a bunch of me too!s.
Keep the snide comments to yourself. Thanks.
So, I finally got around to reading the link Nat sent out:
http://www.perl.com/pub/2001/05/08/exegesis2.html
First off, nice job Damian (as always), it looks excellent. I like the
examples of stuff like this:
my int ($pre, $in, $post) is constant = (0..2);
Awesome. Simple, Perlish, easy
* Nathan Torkington [EMAIL PROTECTED] [05/10/2001 17:31]:
Here's the corresponding perl6 program:
#!/usr/bin/perl -w
while ($ARGS) {
^
Whoa! Is RFC 94 being considered?! I thought I retracted that. ;-)
Notice the variable changes: %count{...} because I'm talking
* Dan Sugalski [EMAIL PROTECTED] [05/11/2001 07:19]:
I think you're in violent agreement here. This has been declared a
goal of Perl 6 from almost day one.
Ok, fair enough, but until just a little bit ago I was hearing stuff different
from Dan. That has been changed, apparently
* Damian Conway [EMAIL PROTECTED] [05/11/2001 14:46]:
Here's a translation table from my soon-to-be-released article, Exegesis 2:
Access through... Perl 5 Perl 6
= == ==
Array slice @foo[$n]
* Larry Wall [EMAIL PROTECTED] [05/10/2001 11:57]:
Nathan Wiger writes:
: Maybe the name Perl should be dropped altogether?
No. The Schemers had to do a name change because the Lisp name had
pretty much already been ruined by divergence.
: (Granted, that's not what I'd prefer
* Dan Sugalski [EMAIL PROTECTED] [05/10/2001 14:18]:
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definately will happen.
Damn straight. One way or another, perl 6 will eat perl 5 code close to
painlessly. (Typeglobs, perhaps,
* Adam Turoff [EMAIL PROTECTED] [05/10/2001 15:20]:
Yes, it has, in Apocolypse 1:
Perl 6 must assume it is being fed Perl 5 code until it knows otherwise.
http://www.perl.com/pub/2001/04/02/wall.html
Yup, I saw that - actually, the discussion I was referencing was
* Peter Scott [EMAIL PROTECTED] [05/10/2001 10:55]:
Eh, I fully understand that version number magnitudes are simply to attract
attention, and that The Faithful don't need the glitz. Since AFAICT the
glitz doesn't hurt, though, it doesn't do any harm to give marketing all
the help it
* Larry Wall [EMAIL PROTECTED] [05/08/2001 10:11]:
Nathan Wiger writes:
: First off, before I forget to mention it, nice job on Apoc2 Larry! You are
: the man. I know alot of us on p6l can seem like harsh critics at times, but
: it's only because we love Perl so much. ;-)
We'll have to do
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:33]:
I'm not against a cleaner way to do qw() in principle, but I
definitely think is not it for a lot of reasons (glob, readline,
can't use =, iterators, ...)
Sheesh. Yes, those would be problems with using in Perl 5.
However, we are
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:46]:
To quote you:
: http://dev.perl.org/rfc/28.pod
I'm not trying to be a jerk at all, but I think at times we're losing
sight of the above.
I hope not, since it was primarily written with you in mind. :)
Hmm, that's odd. As I
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:17]:
Bother. Well, you'd have to quote it, but then you wouldn't really have
a hash key called = that often, either.
Yeah, but you couldn't make use of a way to assign alternate values without
some specialized syntax. I don't think this:
%h
[again, apologies if this is a duplicate]
* Michael G Schwern [EMAIL PROTECTED] [05/04/2001 15:51]:
Oddly enough, varying the number of traffic lights can effect
efficiency. By over-regulating you can choke off traffic. Constant
fiddling with the setups and timings, trying to control each
:$FH = open $file or die Can't open $file: $!;
:$line = next $FH;
:
: If so, I can live with that.
Yes, that's the reason it's Cnext, and not something more specific
like Creadline, which isn't even true in Perl 5 when $/ is mungled.
I dunno. Color me unconvinced--I do use the
Ok, this is long, so here goes...
I expect the real choice is between $FOO and $FOO. I can convince
myself pretty easily that a unary is just another name for next, or
more, or something. On the other hand $FOO has history. And if
one special-cases $..., we could also have foo bar baz as
: This one. I see a filehandle in *boolean* context meaning read to $_,
: just like the current while (FOO) magic we all know and occasionally
: love. I'd expect $FOO.readln (or something less Pascalish) to do an
: explicit readline to a variable other than $_
It would be $FOO.next, but
Horrors is right. The default perl5 behaviour is *useful*. I use the
%b=(%a,%c)
metaphor all of the time.
Why not just keep it simple? And perl5-ish. Two contexts, scalar and list,
hashes NOT a context of its own.
I agree. But what to do with:
(%a, %b) = (%c, %d);
Surely that shouldn't
$a = @b;
2. Pull a reference to @b (like Perl5's $a = \@b)
Yep. Scalar context eval of arrays, hashes, and subs produces a reference.
Perfect.
Similarly, how about:
%c = @d;
Does this:
1. Create a hash w/ alternating keys/vals like
* Michael G Schwern [EMAIL PROTECTED] [05/04/2001 15:51]:
Oddly enough, varying the number of traffic lights can effect
efficiency. By over-regulating you can choke off traffic. Constant
fiddling with the setups and timings, trying to control each and every
intersection to maximize
First off, before I forget to mention it, nice job on Apoc2 Larry! You are
the man. I know alot of us on p6l can seem like harsh critics at times, but
it's only because we love Perl so much. ;-)
Anyways, in addition to the $file.next stuff, I'm curious about a few
clarifications on the new
We do have to worry about the Cnext loop control function though.
It's possible that in
FOO: while (1) {
next FOO if /foo/;
...
}
the CFOO label is actually being recognized as a pseudo-package
name! The loop could well be an object whose full name is CMY::FOO.
Or something
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still
There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:
: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else. I/O handles are a subclass of
: iterators, and I think general
[apologies if this is a duplicate, but my mail's been dropping]
There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:
: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else.
Graham Barr wrote:
You don't get it.
We are not looking for a single char to replace -
We WANT to use .
With complete respect here, I'm still not convinced this is true.
Specifically, what the value of we is. It hardly sounds like
everyone's united on this point. In fact, I've counted
Michael G Schwern wrote:
Oh, not to seed the clouds or anything, but what about += and .=?
Any proposal will have to deal with those.
Under what I originally posted:
$a += $b;# string
$a += $b; # numeric
Seems easy enough...
-Nate
THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're
probably already rolling your eyes. However, I searched p5p all the way
back to 1997 and could not find this proposal anywhere. Even though it
looks similar to the standard Java + concat overload stuff, it is not,
so please try to
Stephen P. Potter wrote:
| In Perl 6, you would do this like so:
|
|$string3 = $string1 + $string2;
Once you go this route, you've pretty much destroyed the usefulness of
having a concat operator. It is far less typing to do
$string3 = $string1$string2;
Agreed. The point
Uri Guttman wrote:
on the other hand, i use .= all the time and wouldn't like to lose
it. schwern idea of ce doesn't work for me as only the op= stuff means
assignment and ce would break that (e for = isn't visual enough).
I was just thinking, too bad that Larry's claiming the colon
Stephen P. Potter wrote:
Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
and !~ went away and were replaced by match(string, [pattern], options),
replace(string, [pattern], options) and trans(string, [pattern], options)
or some such. This is one place where I
Stephen P. Potter wrote:
You still haven't given a good explanation of
$a += sub(); # is it a string or a number?
Does your plan mean that we can no longer have subs that are context
dependent?
No, Schwern asked me this same thing off list, here's what I said:
One possibility:
Larry Wall wrote:
The . is just syntax. Do you mean something semantic by .-based?
No, but I think just syntax is a little misleading. I do agree that we
well, Perl 5 did it this way is not a sufficient design decision at
this point. However, if you changed Perl's syntax too radically you
Larry Wall wrote:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with - as a synonym, just for
John Porter wrote:
One of the reasons I program in Perl as my
primary language is *because of* the syntax.
With all due respect, I don't believe that's why you,
or anyone else, likes to program in Perl.
I *really* don't want this to turn into a religious argument, which it's
fast
Jarkko Hietaniemi wrote:
// numeric comparisons
int (*NUMCMP) (SVAL *this, SVAL *value);
int (*NUMEQ) (SVAL *this, SVAL *value);
int (*NUMNE) (SVAL *this, SVAL *value);
int (*NUMLT) (SVAL *this, SVAL *value);
int
Dan Sugalski wrote:
Besides the size and clunkiness issues, there's another problem. String
evals in a perl 5 section of code will expect to be parsed as perl 5, which
kinda precludes the whole "compile perl 5 to bytecode and pass it through
the p526 converter" solution. Makes mixing and
Ted Ashton wrote:
Thus it was written in the epistle of Michael G Schwern,
I think [Nate]'s saying that its annoying to have to write any tag
that says "Hey, I'm starting a new Perl 6 program here!" at the top of
every single program, much in the same way its tiresome to write "int
Nathan Torkington wrote:
*tap* *tap* is this thing on?
squeal screeech whiz
(lame attempt at a "feedback" joke - ha ha)
Like others, I'm amazed. It looks like Perl 6 is going to be incredibly
coherent, despite the RFC frenzy. For now I have mainly compliments, and
a few thoughts:
1.
[EMAIL PROTECTED] wrote:
Command-line flags on by default [-T -Mstrict -Mwarnings]:
We already beat this to death with the .perlrc discussion. You'll
break reams of Perl code you probably don't even know you have this
way.
It destroys the portability of Perl programs.
Yup, I
[EMAIL PROTECTED] wrote:
But we can run an experiment. Warnings can be made default for the
first few releases of Perl 6 and we'll see what happens. If it looks
good, leave them on. If not, shut them off. Unlike most other
features, this one doesn't have any serious backwards
Branden wrote:
As to the second item b), I would say I withdraw my complaints about `my' if
my other proposal of `use scope' gets approved (since then I don't need `my'
anymore!). I guess I would be happier with `use scope', and I also think it
would make you happier, since it wouldn't
Peter Scott wrote:
At 01:15 PM 2/15/01 -0500, John Porter wrote:
my $a, $b, $c;# only $a is lexically scoped
Quite. But on a tangent, I see no good reason why this shouldn't be given
the same interpretation as "my ($a, $b, $c)" on the grounds that functions
taking list
Peter Scott wrote:
And in any case, make '-e' have the additional connotation that implies
'no strict', and 'no warn'.
no 'warnings'
Seems simple enough to me.
Yes, that's what I thought; but this has generated more heat than light, at
least on the times I've brought it up, e.g.,
[resent to perl6-language, sorry for any duplicates]
Edward Peschko wrote:
I personally think that this is something Larry is going to have to
decide. However, I would like to note that leaving these off by default
lowers the transition curve to Perl 6 immensely for those people that
Dan Sugalski wrote:
The parser needs to have it in a standard system-wide place.
Hmmm. I see what you mean, but why couldn't it be in @INC, first one
wins? The file could be named AutoUse.pm or something.
That strikes me as very much too high level a thing. I'm figuring there
will be
Dan Sugalski wrote:
Regarding #1, if there's no need to make it extensible by users, why
have a file at all? This shouldn't change after Perl is built, right?
And all of the stuff that's going to be "autoloaded" in this way will be
included in the core dist, right? Sounds like some #defines
Damian Conway wrote:
However, it also seems that this is getting *really* complicated
really quickly.
I'd agree. I was picturing the file the parser used reading
something like:
socket|Socket|1.0|gt
I think this is the way to go. I'd suggest that the syntax be easier
Damian Conway wrote:
I like that, though I'd go with different key names ("always" isn't
always, and "tags" is not well related to its effect). How about:
use export implicit = [qw(you get this)],
explicit = [qw(only by request)],
complicit =
Dan Sugalski wrote:
At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
Have a look at AnyLoader in CPAN.
Looks pretty close to what's needed. Care to flesh it out (and streamline
it where needed) to a PDD?
There's also autouse, a pragma that ships with Perl. Again, not exactly
right
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
First off, this looks really cool to me, nice job. The only thing I'm a
little surprised by is this:
=head2 Independent subsystems
Perl also has a number of subsystems that are independent of any
single module.
=item PerlIO subsystem
=item Regex engine
I would have actually expected
The crux of the problem is that non-greedy qualifiers don't affect the
"earliest match" behavior, which makes the matches more greedy than they
really ought to be.
Here is a simple example: (tested with perl 5.005_03)
$_ = "";
($greedy) = /(b.*d)/; #
Kirrily Skud Robert wrote:
Open Source Writers Group (http://oswg.org/) is a good starting point.
I'm subscribed to their mailing list.
This is really cool. Should we consider posting an announcement to this
website for potential docs people? Or is it still premature to do
something like
Simon Cozens wrote:
=head2 Implementation Language
C++ gives us OO and headaches, is wildly non-portable due to a lack of
decent implementations, and we don't have enough experience of it. C's
portable and everyone knows it, but it's a swine for doing OO things.
Don't forget we can
Simon Cozens wrote:
Oh boy, it's OO syntax nargery time again. *sigh*.
I think it would be cool
Good for you. This is internals design; perl6-language is over there ---
and the "ph33r mY |ewl dr3am 5inta" phase is supposed to be over now
anyway.
Cool! Thanks alot for the useful
Steve Fink wrote:
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written by
apprentices, so that non-masters can understand it too.
Except it's a particular duty that nobody really likes to perform.
One thing that might be really cool is if there was a
Adam Turoff wrote:
No worries. These BSD guys are onto something...
http://www.daemonnews.org/200010/dadvocate.html
Thanks for the great link. This is a really interesting article. In
particular, I found these points about FreeBSD to be reminiscient of
concerns some have raised about
Nathan Torkington wrote:
The immediate question facing us is how to structure software design.
This is different from the ongoing maintenance of Perl.
The architecture will be partially decided by Larry, and seems best
done by a few experienced with such things. Detailed design seems
Dan Sugalski wrote:
Just that it not be *too* hard to get on the closed lists
Yep, this is my only concern. It should be reasonably easy to say "I
really want to help" and get on the closed lists. Perhaps the best way
of making sure the lists don't bloat into "everyone has an opinion"
Dan Sugalski wrote:
Works. We still have those Quantum Ninja that we're holding in reserve for
Damian... :)
Yeah... they're vicious, too - they kick ass in constant time. ;-)
-Nate
John Porter wrote:
RFCs like "330: Global dynamic variables should remain the
default" should not need to be written! (No disrespect to you,
Nate.)
None taken; I actually agree. Unfortunately, I thought that -strict did
nowhere near enough analysis of scoping issues besides the initial
Retracting would have been easier, but could very well be seen as giving up
on pointing out PODs deficiencies.
Pointing POD deficiencies is fine. But the fundamental thrust of the RFC
is still "replace POD with XML". That's why I even noted the alternative
names and corresponding emphasis in
However, making it a UNIVERSAL method also dictates that this:
my SomeType @a :someattr;
*must* be either:
1. a builtin type
2. tied
To get its attributes back out. I'm not sure this is going to always be
true.
It must be my sinuses. I don't get that at all.
I may be raining on your RFC 337 parade here (sorry I didn't get to it
earlier - travel), but I think it entirely reasonable to want to specify a
type for an array different from the type of thing it contains. But what
syntax will you use? If I make one up for the sake of illustration:
=head1 CHANGES
Comments received have been that it would be better to use AUTOSCALAR,
AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation.
The argument being that if you only want to implement AUTO scalars in
your program, then doing:
Cif($type_of_thing eq 'scalar') {
Alan Gutierrez wrote:
This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers:
The field value may be preceded by any amount of LWS, though a single SP
is preferred. Header fields can be extended over multiple lines by
preceding each extra line with at least one SP or HT.
Yes, similar
Piers Cawley wrote:
Nathan Wiger [EMAIL PROTECTED] writes:
Another proposal suggests that users should be forced to declare all
variables with Cmy explicitly. Blech. That doesn't make anything
easy. Perl is not a BD language.
Actually Perl *can* be a Bondage Discipline language
=head1 TITLE
Common attribute system to allow user-defined, extensible attributes
Err... have you read perldoc attributes? There's already a mechanism
for doing this (see my japh), though it is a complete PITA to use and
I'd like to see it tidied up (and possibly have attributes.pm
=head1 TITLE
Method calls should not suffer from the action on a distance
Currently,
foo-bar($baz)
can be parsed either as C'foo'-bar($baz), or as Cfoo()-bar($baz)
depending on how the symbol Cfoo was used on other places. The proposal
is to always choose the first meaning: make
David Cantrell wrote:
You can do it by explicitly calling your parent's AUTOGLOB as well if you're
asked to deal with something you don't support yourself (see below). Also,
having it as a single sub would be more easily extensible if we ever have
more datatypes (I think!) and results in
=head1 ABSTRACT
Remove all interpolation within single quotes and the Cq() operator, to
make single quotes 100% shell-like. C\ rather than C\\ gives a single
backslash; use double quotes or Cq() if you need a single quote in your
string.
Yes. If people really need single quotes inside
caller-eval EXPRESSION;
That's mad, bad, scary and dangerous. Let's do it.
Yes, this is cool. In fact, I'm writing Regexp::Func right now as a
prototype for RFC 164 and discovering I could really use this - in fact,
need it.
A couple things:
1. Implement this eval as
Alan Gutierrez wrote:
The suggested C use optimize pragma is starting to grow many heads.
C use less was such a simple little pragma, a general direction for
the interpreter to take. Here it seems that the optimizations apply to
the C package int; only. Are we suggesting that
Simon Cozens wrote:
On Fri, Sep 29, 2000 at 09:47:51PM -, Perl6 RFC Librarian wrote:
I am a fan of Perl and like what I see of the core C# _language_.
What I propose is to move Perl in the C# direction.
So, this is the comedy RFC, eh?
Indeed.
Since you quoted a couple of my RFC's
Simon Cozens wrote:
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
On Wed, 27 Sep 2000, Nathan Wiger wrote:
Y'know, I couldn't have said this better myself. :-) I've always felt
that "use English" was a waste of time and effort, a bandaid trying
We've only got 4 days left until the One True Deadline on this whole
thing. Please, go check this out:
http://dev.perl.org/rfc/overdue-perl6-language-io.html
And get your RFC's finished up. Remember: Oct 1st is a true deadline,
coming from the powers above, meaning if your RFC is not frozen by
A few things I need to point out:
use strict 'objects': a new pragma for using Java-like objects in Perl
RFC 278 had already supposedly claimed "use strict 'objects'", but this
is flexible.
=head2 protected
Just take Conway's RFC 188 and do a s/private/protected/g :-)
So you're
Alan Gutierrez wrote:
I still hope that it doesn't get as complicated as all this. I know
there are arguments out there for specifying integer size and signedness
but I can't imagine that adding this stuff is a good thing.
Key thing: This is all *optional*. This is *not* required. I cannot
We've only got 4 days left until the One True Deadline on this whole
thing. Please, go check this out:
http://dev.perl.org/rfc/overdue-perl6-language-objects.html
And get your RFC's finished up. Remember: Oct 1st is a true deadline,
coming from the powers above, meaning if your RFC is not
Is $$ the only alternative, or did I miss more? I don't think I've even
seen this $$ mentioned before?
$$ is not a suitable alternative. It already means the current process
ID. It really cannot be messed with. And ${$} is identical to $$ by
definition.
I still like the idea of $$, as I
Alan Gutierrez wrote:
This header functionality is application specific and does not belong in
the core any more than the socket stuff which seems to be on its way
out. I don't see why this has be implemented in the core in C.
Once again, if core means core modules, and as a part of
=item *
C\1 goes away as a special form
=item *
$1 means what C\1 currently means (first match in this regex)
=item *
${1} is the same as $1 (first match in this regex)
=item *
${P1} means what $1 currently means (first match in last regex)
Here's the big problem with this, and I
Piers Cawley wrote:
I strongly agree with the opinion that we should try and get away from
special variables and switches in favor of functions and pragmas.
Witness 'use base' instead of '@ISA', 'use warnings', and so on.
Huh? Why??? Perl's use of @ISA is beautiful. It's an example
Tom Christiansen wrote:
So what's left?
print STDERR "Foo";
We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
through.
It is? I certainly hope not. It makes as much sense to
do that as to force a dollar sign on subroutines.
Your point is assuming
A future protocol could well require things in order. Hence you're
having the output headers in order. Therefore you should have the input
ones available in order as well.
I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't
both be supported.
I'm thinking a $headers_in
Rename the Clocal operator
A list of other proposed replacement names includes (but is not
limited to, since I certainly have forgotten some):
Cnow
Unfortunately, I wish this RFC would have taken a stand on at least a
first choice. :-( I always thought that "now" was by far the most
The AUTOGLOB subroutine should expect to take two parameters, the invocant,
and a second parameter specifying what type of item is being AUTOGLOBbed,
followed by - in the case of a sub - the sub's arguments. We suggest that
the second parameter should be a scalar value - 'scalar' for an
Philip Newton wrote:
Is order important for @HEADERS? Would it be better to have %HEADERS
instead that does such auto-formatting?
In my opinion, no, for the reasons given before. Hashes are unordered, and
if you want to order the keys, you need to know the possibly keys and in
which
Damian Conway wrote:
On the matter of gcos or gecos, and passwd or pw_passwd, and all
that noise, please consult the User::pwent manpage.
There's no reason for all those noisy bits.
Since the standard function provides those noisy bits, this proposal
names them.
Note that
1 - 100 of 354 matches
Mail list logo
