NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
You are an idiot (Score:1)
Just look at it:
That’s clearly orders of magnitude easier to read than the Perl version.
Re: (Score:1)
Oh wait, it has to be this:
Or possibly chain the methods.
Perl can’t hold a candle to any of that.
Re: (Score:1)
But perl6 might...
http://xrl.us/ftqq [xrl.us]
http://xrl.us/5obh [xrl.us]
In Python that can be written as:
msg = msg.strip()Re: (Score:1)
msg = msg.strip()Re: (Score:1)
That won’t quite work. Make it
or maybe
Re: (Score:1)
sub strip { s/^\s+//, s/\s+$// for @_ }However I don't like the idea of modifying arguments in place. Functions that do that violate my expectations. Instead I'd make a copy and return the copy. Like this:
sub strip {
return map strip($_), @_ unless 1 == @_;
my $x = shift;
$x =~ s/^\s+//;
$x =~ s/\s+$//;
return $x;
}
Re:You are an idiot (Score:1)
The latter took me a while to read. I’m not used to recursion so casually… and it seems to me that deliberately creating opportunities to get the termination condition wrong is an unnecessary source of bugs.
I agree though that returning a copy is better; I wrote my code that way only because was correcting the example code.
Personally I’d write it like this:
On a related tangent, I’ve often wished for a variant of
s///that modifies a copy of the string and returns that.Reply to This
Parent
Re: (Score:1)
my $bar = strip($foo);Your code will return 1 in that case, while mine returns $foo stripped appropriately.To fix that you would need to check wantarray. Or you could return
@_[0..$#_]instead.Personally I have a lot of utility functions that usually accept one value, but sometimes accepts a list and returns a list. I find it annoying to add the loop and the wantarray check to each one. And I find
Re: (Score:1)
I see the points, but I still don’t like the idiom. It has several moving parts that have to be arranged just so, and you have to read carefully to trace its self-interaction to understand what is really going on.
I prefer to write simpleton code. I also prefer to avoid conditionals for the same reason, so I’d use
@_[0..$#_]overwantarray. All told, for a general-case idiom I’d settle on this:Re: (Score:1)
@_and@_[0..$#_]is (and I'd guess others are also), so MHO is that wantarray would be preferable. I like btilly's way also, though it does make more function calls when run on a list. And on a side note, I also find the title of this thread amusingRe: (Score:1)
I'll note that efficiency depends on your use case. My approach is more efficient for the single argument case. Yours is more efficient for the list case. (More efficient than either of our versions is to make your return depend on a call to wantarray.)
Anyways there was a period where I had to write a bunch o
Re: (Score:1)
Well, I’ve actually written a module to deal with that sort of thing [cpan.org], so…