Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^4: Best practice or cargo cult?

by Juerd (Abbot)
on Jun 20, 2006 at 21:10 UTC ( #556531=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Best practice or cargo cult?
in thread Best practice or cargo cult?

and it's often an error not to use s.

It is, but never forget that it can also be a bad to use /s with .. Matching \n just like any other character is not always natural; this default for . is NOT arbitrary or accidentally introduced. It actually makes sense a lot of the time, and in fact, I encounter more line based data than data that's differently delimited.


Comment on Re^4: Best practice or cargo cult?
Re^5: Best practice or cargo cult?
by ikegami (Pope) on Jun 20, 2006 at 22:17 UTC

    It actually makes sense a lot of the time

    Do you have any examples? I can't think of anything realistic.

    • When dealing with line data, I'd be in a while (<FILE>) { chomp; ... } loops, so my data would never have any \n in it.

    • When dealing with data where \n is considered whitespace, it's no more special than a space, so I'd use the s modifier.

    • When dealing with multiline records, I tend to treat the data as line data — especially if I can use the flip-flop (..) operator — so my data would never have any \n in it. This is probably where I'd be least likely to use the s modifier.

    • When dealing with binary data, \n is not special, so I'd use the s modifier.

      When dealing with line data, I'd be in a while (<FILE>) { chomp; ... } loops, so my data would never have any \n in it.

      Don't forget the single string that contains multiple lines. For the same reason you sometimes want to use /m you sometimes want to match only within a certain line, and then the default . comes in very handy. The difference is that you apparently always read streams line by line, while I like to slurp files from time to time, or get the data in a way that is naturally byte oriented instead of line oriented.

      Hmm... given your realistic world of only four possibilities, /m would also never be needed, so I hope you will be able to understand the argument above :-)

      You should realise that you or I can never, ever, think of all possible ways that other people think of to use something. Some programming language designers also tried this, and their languages are very much unlike Perl. In Perl 6, some features are provided even without any certainty that they will be used, but a discussion like this one convinces me again and again that I do want those features, because not even Larry Wall can think of all the ways someone would ever use Perl. There are reasons to want to match [^\n] easily, even though you couldn't think of any, and fortunately Perl provides this feature.

      And, of course, all these unix tools that behave in exactly the same way should be some indication that even decades ago, already people thought that . matching anything but newline would be very neat!

      Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

        You should realise that you or I can never, ever, think of all possible ways that other people think of to use something.

        That's why I asked. (It wasn't rhetorical.) Thanks for answering.

        And always using the modifiers does not limit you. They only add functionality.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://556531]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (14)
As of 2014-07-24 19:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (166 votes), past polls