Nits

jjore on 2006-11-15T16:26:33

I spent my early evening gagging on some vile code and accompanying text. Instead of emailing my complaints to my work account I'm writing them here. Why not.

Don't use magic (BEGIN + sub()) to avoid saying `use constant'.

Use non-capturing groups (?:...) vs (...) when not capturing.

Use /x and comments in regular expressions.

Use delimiters other than // when the '/' character appears in regexps.

Don't use /o without being able to explain exactly what it does to the optree.


Also

jplindstrom on 2006-11-15T21:17:31

Always document a regex with an example line of text it matches. That makes it sooo much easier for the maintenance programmer to follow along with how the regex is intended to match stuff.

optree knowledge required for /o ?

Limbic Region on 2006-11-15T21:28:36

You had me up till this one. If knowledge of the optree is required and the docs aren't sufficient to understand - you should submit patches to the docs.

From perlop:
PATTERN may contain variables, which will be interpolated (and the pattern recompiled) every time the pattern search is evaluated, except for when the delimiter is a single quote. (Note that $( , $) , and $| are not interpolated because they look like end-of-string tests.) If you want such a pattern to be compiled only once, add a /o after the trailing delimiter. This avoids expensive run-time recompilations, and is useful when the value you are interpolating won't change over the life of the script. However, mentioning /o constitutes a promise that you won't change the variables in the pattern. If you change them, Perl won't even notice.

and then later on as an example

# poor man's grep
$arg = shift;
while (<>) {
    print if /$arg/o;  # compile only once
}

Yes, I have read http://perlmonks.org/?node_id=269035. It still doesn't help the thousands upon thousands of users that haven't heard of PerlMonks. Requiring the level of knowledge you are indicating is necessary to use a feature of the language is ridiculous. We all know you are smart - help those less knowledgeable by submitting patches to the documentation.

Cheers - L~R

Re:optree knowledge required for /o ?

jjore on 2006-11-15T21:46:24

Well... ok... but I think only wizards should be using /o. If you aren't at that level then use qr// like everyone else. Ignoring that /o existed prior to qr//, for today's perl /o is just a minor optimization over qr//.

It's like symbolic references. You shouldn't be allowed to use them until you can explain why you're not supposed to use them.

Re:optree knowledge required for /o ?

Abigail on 2006-11-16T08:27:07

Actually, I think noone should use /o. At least not on a Perl that has been released in a year that starts with a 2. The magic /o is useful for is now already be done by Perl by default. If the value of your variable won't change, the regexp won't be recompiled anyway.

The only difference you will notice when using /o is when the variable inside the regexp does change. But IMO, you really don't want a regexp that doesn't recompile when the variable does change.

Re:optree knowledge required for /o ?

jjore on 2006-11-16T15:38:15

/o vs re-using a qr// value saves dispatching one opcode.

Re:optree knowledge required for /o ?

Aristotle on 2006-11-17T02:38:55

And that matters when exactly? :-)

Re:optree knowledge required for /o ?

jjore on 2006-11-17T16:43:01

In areas you think are tight loops. I've also replaced if(not ...) with unless(...) just to avoid dispatching another opcode.

I'm sure it's wasted effort since I know humans are bad at guessing what'll need optimization. I still wish to be slightly deluded that the opcode I saved by using /o was good. Only *slightly* though.

Re:optree knowledge required for /o ?

Abigail on 2006-11-20T08:39:52

That of course depends on how often you reuse. Storing a qr means you have to assign to a variable, which means the variable has to be created, removed (presuming you're using a lexical variable with a small scope) and assigned to. Surely that takes a few opcodes as well?

Not that I really care about a single saved opcode.

`use constant` considered pointless

Aristotle on 2006-11-17T02:41:25

I’ve been kinda leaning away from it. Although I don’t know why one would put one’s constant subs in a BEGIN block; I just list them at the top of my code. I see little point in loading such minor syntactic sugar as constant.pm, particularly as many people don’t realise how “constants” work.

Re:`use constant` considered pointless

jjore on 2006-11-17T16:40:23

What I'd just read went somewhat as follows. It was clearly an attempt to replicate constant.pm's work but badly.
BEGIN {
    *{ __PACKAGE__ . '::DEBUG' } = sub () {
        ...
    }
}

Re:`use constant` considered pointless

Aristotle on 2006-11-17T17:26:08

Ugh. That is awful, no argument. Would’ve been entirely sufficient to write

sub DEBUG () { 1 }