Re: Re: a word of warning about /$pattern/

This kind of thing keeps me humble, because I know that somewhere there is someone who understands exactly why this was a good idea

Its still a good idea:

if (/foo/ or /bop/ or /fnorble/) {
  s//baz/;
}
[download]

IOW, it means you can have several regexes try to match, and then without having to worry about which one did you can then replace the thing that was matched. I only recently came accross this feature, but sice I have its found its way into more code than I thought it would.

---
demerphq

_{First they ignore you, then they laugh at you, then they fight you, then you win.

-- Gandhi}

Comment on Re: Re: a word of warning about /$pattern/ Select or Download Code

Replies are listed 'Best First'.
Re^3: a word of warning about /$pattern/ by Aristotle (Chancellor) on Dec 07, 2003 at 09:43 UTC
Huh? `s/foo\|bop\|fnorble/baz/;` [download] Makeshifts last the longest.	[reply] [d/l]
Re: Re^3: a word of warning about /$pattern/ by demerphq (Chancellor) on Dec 07, 2003 at 18:06 UTC
Fair point. The example is not the best I've ever written. The point is that the empty regex behaviour is useful for allowing you to use m/.../ and then later s//.../ without having to match a second time. Maybe this is better `if ($foo and /bar/) { print "Condition suceeds.\n"; if ($bloop and /bop/) { #... } # do other stuff, maybe even exit... s//baz/; # switch bar or bop with baz depending # on a bunch of things that have already happened. }` [download] Hopefully now you see the point? Sure we could probably rework the logic so this isnt needed, but I like the possibilities this opens up. :-) --- demerphq _{First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi}	[reply] [d/l] [select]
Re^5: a word of warning about /$pattern/ by Aristotle (Chancellor) on Dec 08, 2003 at 06:20 UTC
Oh, I understand what you were getting at. I still see it as somewhat obfuscatory though. I also don't really like it conceptually, as the `s///` is actually doing the match from scratch (so it's not an atomic operation). It might still be the best way to go about this problem, I don't know: I don't remember ever having to have needed to implement such logic so I have no realistic example scenario to go by. I just can't help the feeling that there has to be a clearer way. Makeshifts last the longest.	[reply]


go ahead... be a heretic
	PerlMonks