Re: RFC 361 (v1) Simplifying split()

2000-10-07 Thread Jonathan Scott Duff
On Sat, Oct 07, 2000 at 10:38:21AM +0200, Bart Lateur wrote: > On Fri, 6 Oct 2000 23:26:44 -0500, Jonathan Scott Duff wrote: > > > @foo = split; > > # BECOMES > > @foo = split; pop @foo until $foo[-1]; > > That doesn't fly. What if that last field is "0"? > > > > @foo = split '

Re: RFC 361 (v1) Simplifying split()

2000-10-07 Thread Bart Lateur
On Fri, 6 Oct 2000 23:26:44 -0500, Jonathan Scott Duff wrote: > @foo = split; > # BECOMES > @foo = split; pop @foo until $foo[-1]; That doesn't fly. What if that last field is "0"? > @foo = split ' '; > # BECOMES > @foo = split /\s+/; shift @foo; What if th

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread Jonathan Scott Duff
On Fri, Oct 06, 2000 at 11:59:31AM -0600, Sean M. Burke wrote: > The current behavior makes trailing empty fields non-existent, and that's a > bizarre and nonintuitive thing to have be a default; if your code relies on > them being removed, then remove them explicitly, without expecting split to >

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread Chaim Frenkel
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> The reason that this was done this way was for the common TC> case of someone forgetting to chop an incoming line and TC> then splitting on whitespace. TC> while (<>) { TC> @F = split; TC> ... TC> } Interesting. I t

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread Tom Christiansen
>Sean M. Burke wrote: >> >> The current behavior makes trailing empty fields non-existent, and that's a >> bizarre and nonintuitive thing to have be a default; >Only to some people; and besides, it's well documented. Well, Sean is right in that it is very bizarre to many people. I know that whe

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread John Porter
Sean M. Burke wrote: > > The current behavior makes trailing empty fields non-existent, and that's a > bizarre and nonintuitive thing to have be a default; Only to some people; and besides, it's well documented. > if your code relies on > them being removed, then remove them explicitly, withou

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread Tom Christiansen
The reason that this was done this way was for the common case of someone forgetting to chop an incoming line and then splitting on whitespace. while (<>) { @F = split; ... }

Re: RFC 361 (v1) Simplifying split()

2000-10-06 Thread Sean M. Burke
At 12:37 AM 2000-10-06 -0400, you wrote: >> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > >PRL> =item 2. Empty trailing fields are currently suppressed (although a >PRL> -1 as the third argument disables this). I suggest that empty trailing >PRL> fields be retained by default. >

Re: RFC 361 (v1) Simplifying split()

2000-10-05 Thread Chaim Frenkel
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =item 2. Empty trailing fields are currently suppressed (although a PRL> -1 as the third argument disables this). I suggest that empty trailing PRL> fields be retained by default. Extremely useful, I rely on this. It makes non-

Re: RFC 361 (v1) Simplifying split()

2000-10-01 Thread Bart Lateur
On Sun, 01 Oct 2000 11:18:58 +0200, Bart Lateur wrote: > my @a = split /:/, "", -1; Oops. that should be my @a = split /:/, $_, -1; -- Bart.

Re: RFC 361 (v1) Simplifying split()

2000-10-01 Thread Bart Lateur
On 1 Oct 2000 06:40:08 -, Perl6 RFC Librarian wrote: >Perl 5 split does five things that I think are just annoying, and >which I suggest be removed: I've got one more problem. for my $i (0 .. 4) { $_ = ':' x $i; my @a = split /:/, "", -1; my $coun

RFC 361 (v1) Simplifying split()

2000-09-30 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Simplifying split() =head1 VERSION Maintainer: Sean M. Burke <[EMAIL PROTECTED]> Date: 30 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 361 Version: 1 Status: Developing =head1 ABSTRACT Per