Bart Lateur wrote:
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This empowers
them. Making them learn yet-another-function-call merely hamstrings
them with
Bart Lateur wrote:
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This empowers
them. Making them learn yet-another-function-call merely hamstrings
them with
I already proposed that. Benchmarks show that reading a file with
explicit chomp() is easily 20% slower than reading the same file with
implicit chomp(), through the -l command line switch.
And what, pray tell, do you do about the small matter of wanting
to read some files without implicit
Eric Roode writes:
Useful functions all, no doubt. But I would lobby heavily for a new
set of names -- ones that can be remembered! Quick -- which trims
leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
On Thu, 31 Aug 2000 19:59:31 +0200, you wrotc:
tr/\w//dlt # Trim all leading trailing whitespace from $_
Eh, scratch that. Too much caffeine i guess.
tr/\n\r\t //dlt; # Trim some whitespace.
-DZ
--
Tell me your dreams and I will crush them.
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
Why not use the "function" we already got, tr? Something like:
tr///l # Translate only _l_eading characters matching.
tr///t # Translate only _t_railing characters matching.
With "Only leading" I mean translate
At 01:35 PM 8/31/00 -0500, Jonathan Scott Duff wrote:
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
Why not use the "function" we already got, tr? Something like:
tr///l # Translate only _l_eading characters matching.
tr///t # Translate only _t_railing
On Thu, Aug 31, 2000 at 02:52:10PM -0400, Buddha Buck wrote:
How would you do:
# Writer insists on blank line between paragraphs, first line indented.
# Publisher insists on one paragraph/line, first word ALL CAPS.
{
local $/ = ""; #slurp paragraph at a time.
while (INFILE) {
How would you do:
# Writer insists on blank line between paragraphs, first line indented.
# Publisher insists on one paragraph/line, first word ALL CAPS.
Step 1: Fire the lame publisher. I'm serious. It's amazing
what people tolerate. Some things aren't worth the pane.
{
local $/ = "";
TomC wrote:
In general, getting folks to write
s/^\s+//s;
s/\s+$//s; # XXX: \z
is a *good* think.
Why?
Removing leading/trailing whitespace is a tremendously frequently-
performed task. Perl gives you -l on the command line to strip
newlines on input and add them on output, simply
I'm not arguing in favor of the tr/// hack specifically, but
gosh, wouldn't it be nice if there were a thwack() builtin that
stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
I'm not arguing in favor of the tr/// hack specifically, but
gosh, wouldn't it be nice if there were a thwack() builtin that
stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
My first reaction was "NOOO!!" we'll break too much code!
Now, I'm not so sure. Nearly always, chomp() is what is called for;
how often *do* you need to chop off the last character of a string?
And, as someone else pointed out, why not the first character?
"Al" wrote:
I would actualy
On Wed, Aug 30, 2000 at 04:34:50PM -0600, Nathan Torkington wrote:
I wouldn't go that far. It might say something about the difference
between proposals made as rhetorical devices ("yes, but if that's the
case then you should be getting rid of X, Y, and Z!"). Really, though,
I think it's
Tom Christiansen wrote:
I'll second that motion. We already have lots of ways of removing the
last character of a string if that's what we really need.
But they're slow and hard to read.
I think the word "drop" should be clarified as "dropped from the core
binary".
In a very cool email,
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Nat
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
I'll second that motion. We already have lots of ways of removing the
last character of a string if that's what we really
Ed Mills writes:
Duck cover Nate- I sugested that weeks ago and the flames are just dying
down in my mailbox..
Whoops, sorry. I didn't realize that had already been submitted.
I just read through the mail archive and didn't see much in the way of
flames there. J.S. Duff wants to keep
the reason that they're duplicatable with other features, while I want
to drop chop because its main purpose has now been replaced with the
far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the source of the data being chomped.
--tom
Tom Christiansen writes:
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things above to be
I presume that line disciplines will be object-oriented and inherit from
some base class; therefore a bare chomp will use the line terminator from
that base class and for the others, you could do something like
$fh-chomp($line) to do chomping specific to a particular filehandle. Make
sense?
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Works for me. Are you going to RFC it?
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open Source
22 matches
Mail list logo
