while we’re still on it, i wonder whose decision it is to remove perl’s
dual //s + //m modifiers and just adopt //s (that is, “.” will match a
newline) and treat ^ & $ line-wise regardless of the modifiers. was it
matz’s? i think this is a fine design decision, since many people have
trouble understanding //s and //m.
but i wonder why the chosen name is MULTILINE (//m) instead of
SINGLELINE (//s), and moreover why doesn’t ruby complain when i give an
s modifier. this has bitten me a couple of times in the past, since i
often use the s modifier in my perl regexes. i believe many perl
programmers were/will be bitten by this one.
while we’re still on it, i wonder whose decision it is to remove perl’s
dual //s + //m modifiers and just adopt //s (that is, “.” will match a
newline) and treat ^ & $ line-wise regardless of the modifiers. was it
matz’s? i think this is a fine design decision, since many people have
trouble understanding //s and //m.
All Ruby decisions are matz’s, as far as I know I like this one
too, especially in conjunction with \A, \Z, \z.
but i wonder why the chosen name is MULTILINE (//m) instead of
SINGLELINE (//s), and moreover why doesn’t ruby complain when i give an
s modifier. this has bitten me a couple of times in the past, since i
often use the s modifier in my perl regexes. i believe many perl
programmers were/will be bitten by this one.
Hmmm. I guess you could argue that making . include \n means that
matches more easily straddle multiple lines. Also, since $ and ^
always address the string line-wise, it’s sort of misleading to
describe it as treating the string as a single line.
but i wonder why the chosen name is MULTILINE (//m) instead of
SINGLELINE (//s), and moreover why doesn’t ruby complain when i give an
//s means SJIS encoding
ruby has support for multibyte sequences
oh, sorry. i wasn’t reading the documentation carefully enough. but then
why does the lang parameter consume the lowercase and the uppercase
character as well? couldn’t SJIS encoding just given the parameter ‘S’
instead of ‘s’ and ‘S’?
Hmmm. I guess you could argue that making . include \n means that
matches more easily straddle multiple lines. Also, since $ and ^
always address the string line-wise, it’s sort of misleading to
describe it as treating the string as a single line.
well, “single line” or “multiple line” is just a matter of terminology.
but traditionally “single line” (s modifier) has meant ‘matching “\n”
for .’, so the ruby terminology “multiple line” is at odds with perl’s
re, pcre, python’s re, and perhaps most others too. i suspect (though
not blame) matz chose the “m” instead of “s” because he wanted “s” to
mean “SJIS” so it’s easier to remember for japanese people.
well, “single line” or “multiple line” is just a matter of terminology.
but traditionally “single line” (s modifier) has meant ‘matching “\n”
for .’, so the ruby terminology “multiple line” is at odds with perl’s
re, pcre, python’s re, and perhaps most others too. i suspect (though
not blame) matz chose the “m” instead of “s” because he wanted “s” to
mean “SJIS” so it’s easier to remember for japanese people.
Agreed. Besides I felt Perl’s combination of /s and /m was insane.
I like this one