> "RP" == Richard Proctor <[EMAIL PROTECTED]> writes:
>> Perhaps $/ and $\ should become per-filehandle variables, and
>> there should be some way to set autochomp-on-read per filehandle,
>> and auto-newline-on-output per filehandle.
RP> I can see a small benefit for autochomp-on-read but n
Richard Proctor wrote:
>>[Eric Roode wrote]
>> Perhaps $/ and $\ should become per-filehandle variables, and
>> there should be some way to set autochomp-on-read per filehandle,
>> and auto-newline-on-output per filehandle.
>
>I can see a small benefit for autochomp-on-read but none whatsoever
>f
Today around 11:17am, Nathan Wiger hammered out this masterpiece:
: "Bryan C. Warnock" wrote:
: >
: > Someone, (and I've lost who, exactly) was interested in taking those
: > off my hands for a String::Utils module.
:
: I believe I volunteered for this; not sure if anyone else did, but I'm
: mo
On Fri 08 Sep, Eric Roode wrote:
> Does anyone EVER use chomp() except shortly after reading a line
> of input from a stream? No?
>
Yes
> Perhaps $/ and $\ should become per-filehandle variables, and
> there should be some way to set autochomp-on-read per filehandle,
> and auto-newline-on-out
"Bryan C. Warnock" wrote:
>
> Someone, (and I've lost who, exactly) was interested in taking those
> off my hands for a String::Utils module.
I believe I volunteered for this; not sure if anyone else did, but I'm
more than willing to do this.
-Nate
Does anyone EVER use chomp() except shortly after reading a line
of input from a stream? No?
Perhaps $/ and $\ should become per-filehandle variables, and
there should be some way to set autochomp-on-read per filehandle,
and auto-newline-on-output per filehandle.
Then, if anyone ever needs to
> Shoot chop. and chomp. Unless you add unchop and unchomp.
C *has* an inverse.
Surely you know about the unary postfix C<.$/> operator?
Of course, you have to be careful. There's a known bug that
the C<.$/> doesn't properly "unchomp" if you've ever used the
C<$/&=``> operator.
;-)
Damian
On Fri, Sep 08, 2000 at 02:50:37AM +, Ed Mills wrote:
> Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
> a language with YES and no NO.
>
> Just kill then both.
Although I'm rather fond of symmetry, it's not inherently good.
Rather boring if overused.
I admit
>Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
>a language with YES and no NO.
By that criterion, you have zillions of other things to kill.
>Just kill then both.
I don't think this will win us friends.
--tom
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
Just kill then both.
>From: Bryan C. Warnock <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Michael G Schwern <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>
On Thu, 07 Sep 2000, Michael G Schwern wrote:
> Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
Someone, (and I've lost who, exactly) was interested in taking those
off my hands for a String::Utils module.
I believe it was quite clear, however, that my root-and-measure-deri
> > 'Pends on whether you modulate them.
>
> KCHP 1570 on your AM dial!
Aw, not *another* one of those easy-listening Californian motor cop stations!
Damian
On Thu, Sep 07, 2000 at 06:48:35PM -0600, Tom Christiansen wrote:
> >Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
>
> 'Pends on whether you modulate them.
KCHP 1570 on your AM dial!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just A
>On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
>> =head1 TITLE
>>
>> Retire chop().
>Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
--tom
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 195
Status: Developing
=head1 ABSTRACT
Remov
16 matches
Mail list logo
