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
* 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
* Jonathan Scott Duff [EMAIL PROTECTED] [05/21/2001 09:39]:
If anything, all variables should have a value property that evaluates
to its, well, value and only that property would be considered in
conditionals. Then these would be equivalent:
print keys (+$foo).prop;
print
* 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
* 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
* Larry Wall [EMAIL PROTECTED] [05/08/2001 09:36]:
Taking history into account is good, though I'd argue that now is the
proper time to change history, if we're going to change. Perl would
never have been accepted in the first place had it been too different
from what came before, but now
* 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/05/2001 17:51]:
%foo = ( foo = 1, bar = 1, '=' = 'baz' )
Of course, that could be spelt
%foo = +foo +bar =(baz);
Actually, it couldn't be because the in = would end the parsing.
Same problem that the POD chars have.
I think Uri's qh() suggestion
* 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
:$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
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.
: 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
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
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
$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
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
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
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
I'm just gonna post this, then back off and listen (been yapping too
much...)
The previous discussions about string concat and how to replace . have
revealed that people are somewhat divided over whether replacing - with
. is actually good thing or not.
I'm just curious what the arguments for
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
Michael G Schwern wrote:
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
ok, well.. I've heard arguments for '+' (namely that its intuitive, other
language compatible, etc...) so what are the arguments against it?
This one seems to have slipped by...
Michael G Schwern wrote:
cc and ce
Perl 5 Perl 6
print foo . bar;print foo cc bar;
print 2 . 4;print 2 cc 4;
print foo . ($i + 1);print foo cc ($i + 1);
$foo .= bar ;
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
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:
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:
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
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
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
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
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
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:
Where should this info be maintained? In a module in @INC (sort of like
CPAN/MyConfig.pm)? Or in a special file that's only written to via a
module install? Or in a block atop each module that's yanked out via
MakeMaker? Or???
The parser needs to
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
Ted Ashton wrote:
It appears to me that there's a focus problem here. After all,
if I want to use CGI or CGI::Minimal, I can already do that.
The auto-autoloading, unless I am sorely mistaken (which is
quite possible :-), is for the purpose of moving things out
of the core and yet
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
"Stephen P. Potter" wrote:
Why do we have to worry about changing time()? There's a real parallel
between sleep() and alarm(), so we would want to do both if we did either,
but time() really has no relation to them.
Or, should we just implement usleep() and (for lack of a better name)
Simon Cozens wrote:
On Thu, Oct 19, 2000 at 04:47:10PM +0100, raptor wrote:
What will be the Perl6 code name ?
I vote for "Perl 6".
How about "P2L6" - or even "P36"? (kidding) ;-)
-Nate
=head1 TITLE
Perl should use XML for documentation instead of POD
=head1 VERSION
Status: Frozen
I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's
like this when the following is true:
A lot of good, heated discussion was generated on the mailing lists. The
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
There's two ways I've proposed in different RFC's. The first one
utilizes a more general framework; the second one depends on Ctie
being used. A UNIVERSAL:: method wouldn't work because you've got to get
attributes from arrays and hashes as well.
Maybe I'm just being dense, but why
"David L. Nicol" wrote:
Bart Lateur wrote:
Bitwise and, or and xor do distinguish strings from numbers, and return
entirely different kinds of results. Why can't anything else?
Absolutely. There is such a thing as Too Much Convenience. I think
BOOL as a context or an accessor
=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') {
I believe that mentioning an attribute of a variable is
really a method call on the variable's underlying object --
which, in perl6, can have user-definable behavior.
Where some language use dot or arrow syntax, perl uses colon.
Very isomorphic.
Please tell me I'm right! :-)
Pretty
Bart Lateur wrote:
My idea is that if anybody sets $[ to 1 in a script, all accesses to
array in that script would use 1 as the index of the very first item:
$ary[1]. But if you pass this array (for example, a reference to it) to
a function in a module that doesn't set $[, it would access
Two of POD's deficiencies are list handling and table handling. POD
doesn't handle tables right now, but calling this easy to write
or easy to read is ludicrous:
[horrendous XHTML and DocBook notations deleted]
I think POD's list handling is full of warts, but what follows
is much better
I haven't got around to RFCing the more generic version (that all attributes
are inherited inside nested data types), but that would certainly be a nice
approach.
RFC 337...the new version I just sent in says:
This would allow those who want to to warp Perl OO into Java
or Python or
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
you would do:
$sock = AIO::Open( Host = 'www.perl.org',
Port = 80 ) ;
Similarly for LWP you would just do:
$sock = AIO::Open( Url = 'http://www.perl.org' ) ;
$event = AIO::Open( Host = 'www.perl.org',
Port
Hm. This makes it difficult to construct a header incrementally -- for
example, @HEADERS=(); push @HEADERS, header(content_type='a',
author='b'); # 75 lines later; push @HEADERS, header(last_modified='c',
accept='d');
Since in this case, there would be two "blank" head lines instead of
=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
=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
=head1 ABSTRACT
An unscoped eval is needed. It is part of the necessary steps to
make Perl palatable as an interactive shell.
I agree with Michael that the syntax is not suitable. If it's a separate
function, then it needs to be a \w+ name.
You should check out RFC 339 - it talks about a
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
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
=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
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
Jonathan Scott Duff wrote:
My first thought was "this should definitely be in a module" and your
comments just fire those synapses even more strongly.
Yes, this will likely end up in a core module. The main thing is that it
always has to be available so that pragmas like "use cgi" can import
PS un is such a lame prefix and very un perl like... unjoin? unpush?
okay so unshift, but still... hey wait I want undelete!
Heh. :-) This is not really true, in fact within Perl it is the One True
Prefix, ala undef, unlink, unpack, unshift, untie...
-Nate
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
James Mastros wrote:
As far as setting|getting, I'd like to make a simple proposal. Consider it
an idea for whoever writes the RFC (I'm looking at you, Nate)
Oh, jeez, as if I didn't have enough already! ;-)
The idea is this: every variable should have a psudohash of attributes.
Idea is
Bart Lateur wrote:
The problem is that
$name = "myarray";
@$name = (1,2,3);
print @$name[0,1]; # 1,2
Is very consistent currently. Change one and you have to change the
precedence and parsing of all symbolic refs.
You are suggesting to keep a weird precedence rule, just
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
David Grove wrote:
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote:
This is screaming mad. I will become perl6's greatest detractor and
anti-campaigner if this nullcrap happens. And I will never shut up
about it,
either. Mark my words.
Quote from Larry: "I have
Adam Turoff wrote:
PRL -r freadable()
PRL -w fwriteable()
PRL -x fexecable()
PRL -o fowned()
PRL -R Freadable()
PRL -W Fwriteable()
PRL -X Fexecable()
PRL -O Fowned()
this looks decent to me.
I reserve the right to
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
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
Sounds good. I'll start on my 39th :-{ RFC right now... ;-)
-Nate
Adam Turoff wrote:
On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
Ziggy, are you interested in this idea enough (at all?) to stick a note
about the 'header' function into the RFC? Or should I RFC
Dan Sugalski wrote:
Because taint mode needs to be turned on REEELY early, like before
pragmas are compiled.
'no taint' does make sense, though 'use taint' might not except to locally
undo 'no taint'.
Actually, from my talks with Larry both on and off-list about this, he
convinced me
Russ Allbery wrote:
I've found the use of use English in code I had to maintain to be annoying
and unhelpful, and to actually degrade the maintainability of the code
[snip]
I've yet to understand why I'd *want* to use English regularly; so far as
I can tell, it has essentially no benefit in
My personal feeling is that I'd love "use English" to be expunged from
the language altogether - it's unnecessary bloat that only increases the
number of mistakes that people can make. But I'm not sure if I have the
guts to write that RFC just yet. ;-)
Are you talking about the
Adam Turoff wrote:
It has nothing to do with improving the syntax though, because everything
in use English is a variable that serves as a reference to some other
variable.
Yes, and that's why I really think it's a waste of time. ;-)
I'm not vehemently opposed to "use English"... But I
Dan Sugalski wrote:
It might be nice if the result of a calculation was never tainted when the
calculation was in a 'no taint' block.
Yerk. No, that's bad. The data is still tainted--the fact that it flowed
through a "no taint" block doesn't make it any more trustworthy. Tainting
really
Robert Mathews wrote:
Parse the CGI GET/POST request, returning CGI variables into %CGI
(regardless of the source) in an un-HTTP escaped fashion
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
Are you going to
I'm kind of curious to know what you think would happen with the
following. I've commented where I'm confident...
interface Number;
sub TIESCALAR;
sub STORE;
sub FETCH;
package integer implements Number; # I really like this notation
Tangentially, yes, it is nice
Simon Cozens wrote:
Looks great on scalars, but...
@foo =~ shift; # @foo = $foo[0] ?
@foo =~ unshift; # @foo = $foo[-1] ?
Yes, if you wanted to do something that twisted. :-) It probably makes
more sense to do something like these:
@array =~ reverse;
@vals =~ sort { $a =
The http_header() is a straw man intended to demonstrate that there
are issues with shoving all of the outgoing HTTP headers into a simple
variable. Not insoluable problems, but problems.
Agreed.
I do like the idea of stacking HTTP headers and queueing them up
before the first print
Adam Turoff wrote:
That's a stone's throw awaty from:
import english
from english import filetest
result = filetest.readable("/dev/null")
I think the common prefix idea is a nonstarter. There must be a way
to coming up with sensible names for all of -X that
Uri Guttman wrote:
not the best. would that be confused with a sub readable and a leading
unary negation? in fact how does perl parse -r now vs - r()?
Yes it would, here's how Perl parses these right now:
perl -w -e '
sub r { local $\; print "r(@_) : "; }
$\ = "\n";
print "-r" if -r
File tests (-r/-w/-x/...) made sense when Perl's shellness was an
attribute. Most new Perl programmers are not coming from a shell
programming background, and the -X syntax is opaque and bizarre.
It should be removed.
Perl programmers happy with the -X syntax will need to get used to the
1 - 100 of 380 matches
Mail list logo
