PATCH: S04 - unary C= is not slurpy

2005-06-15 Thread Patrick R. Michaud
Based on an off-list discussion, it turns out that unary C=
is not slurpy as mentioned in S04.  The following patch to S04
corrects this; I've already applied the patch but thought I'd
pass it by p6l for review/comments/reactions.

Pm

Index: S04.pod
===
--- S04.pod (revision 3802)
+++ S04.pod (working copy)
@@ -12,7 +12,7 @@
 
   Maintainer: Larry Wall [EMAIL PROTECTED]
   Date: 19 Aug 2004
-  Last Modified: 29 Jan 2005
+  Last Modified: 15 Jun 2005
   Number: 4
   Version: 5
 
@@ -185,13 +185,10 @@
 This has the added benefit of limiting the scope of the C$line
 parameter to the block it's bound to.  (The Cwhile's declaration of
 C$line continues to be visible past the end of the block.  Remember,
-no implicit block scopes.)  It is possible to write
+no implicit block scopes.)  It is also possible to write
 
 while =$*IN - $line {...}
 
-But it won't do what you expect, because unary C= does a slurp in scalar
-context, so C$line will contain the entire file.
-
 Note also that Perl 5's special rule causing
 
 while () {...}


Re: PATCH: S04 - unary C= is not slurpy

2005-06-15 Thread Autrijus Tang
On Wed, Jun 15, 2005 at 05:37:18PM -0500, Patrick R. Michaud wrote:
 Based on an off-list discussion, it turns out that unary C=
 is not slurpy as mentioned in S04.  The following patch to S04
 corrects this; I've already applied the patch but thought I'd
 pass it by p6l for review/comments/reactions.

Does it mean that it's a synonym to readline?

Thanks,
/Autrijus/


pgpGE4T1lI9Ej.pgp
Description: PGP signature


Re: PATCH: S04 - unary C= is not slurpy

2005-06-15 Thread Damian Conway

Autrijus asked:


On Wed, Jun 15, 2005 at 05:37:18PM -0500, Patrick R. Michaud wrote:


Based on an off-list discussion, it turns out that unary C=
is not slurpy as mentioned in S04.  The following patch to S04
corrects this; I've already applied the patch but thought I'd
pass it by p6l for review/comments/reactions.



Does it mean that it's a synonym to readline?


No. It's the general-purpose iterate this... operator.

Applied to a filehandle, it iterates the filehandle (which *is* equivalent to 
 calling Creadline).


But it can also be applied to any other iterator object, in which case it 
calls that object's C.next method.


Damian