Problems? Is your data what you think it is? | |
PerlMonks |
Re^5: Opinion: where Perl5 wasn't attractive for meby davido (Cardinal) |
on Nov 20, 2014 at 15:56 UTC ( [id://1107941]=note: print w/replies, xml ) | Need Help?? |
If that's what you were talking about with respect to reverse (though the original post failed to demonstrate it), then congratulations. On that bullet point you have hit upon an actual poor design decision that could have gone a different direction without negatively impacting some other priority. Even the creator of Perl has admitted it seemed like a good idea at the time but may not have been. Every aspect of every language is a design decision. The answers to some decisions lock down the answer to others, in many cases. But reverse was a design decision that could have gone a different direction without trading off some other feature. chomp, on the other hand, really does the right thing. I know in a perfect world we hate functions with side effects, but in this case the side effect means we can act upon the operand rather than allocating and copying to a new container. The return value of chomp is mostly irrelevant. But what should it return? Certainly we don't want to have to waste the time and space necessary for copying the unchomped string into the container on the lefthand side of =. So in the case of reverse, there would have been no real negative impact to make the behavior more consistent and predictable. Particularly the fact that it silently concatenates lists when called in scalar context is confusing to people. But on the other hand, changing chomp to not work in-place, but instead to return a chomped version of its parameter list, that would create a performance impact, so that design decision was pretty clearly a good one; favor performance. Dave
In Section
Meditations
|
|