Nathan Torkington wrote: > > Nathan Wiger writes: > > $x =~ /a/; # $x is roughly equivalent to a > > I've been going at high speed through this thread, but has > anyone mentioned: > > m{$foo}{^baz.*bar$}i > s{$foo}{(\w+) \1}{$1}g > > With the first part of m{} and s{} containing an expression. Personally, if we're going to consider this route, I say we go all the way and just make them builtin functions: m($foo, '^baz.*bar$', i); s($foo, '(\w+) \1', '$1', g); Yech! I take that back. But it is much more consistent. Although I'm still missing what the big todo is about =~ and !~, why they're so difficult compared to == and !=, and why they make so little sense and make things so hard. I love m// and s/// as-is. I would be very sad if they were changed without bigtime gains in functionality. :-( But one thing that would be cool is supporting full functions in the left side of a pattern: $string =~ m/$r->getpattern/ie; Now that would be cool. -Nate
- Re: RFC 138 (v1) Eliminate =~ operator. Mark-Jason Dominus
- Re: RFC 138 (v1) Eliminate =~ operator. Steve Fink
- Re: RFC 138 (v1) Eliminate =~ operator. Larry Wall
- Re: RFC 138 (v1) Eliminate =~ operator. Steve Fink
- Re: RFC 138 (v1) Eliminate =~ operator... Jarkko Hietaniemi
- Re: RFC 138 (v1) Eliminate =~ operator... Damian Conway
- Re: RFC 138 (v1) Eliminate =~ operator. Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator... Steve Fink
- Re: RFC 138 (v1) Eliminate =~ ope... Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator... Nathan Torkington
- Re: RFC 138 (v1) Eliminate =~ ope... Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~... Nathan Torkington
- Re: RFC 138 (v1) Eliminat... Tom Christiansen
- Re: RFC 138 (v1) Eliminat... Nathan Torkington
- Re: RFC 138 (v1) Eliminat... Nathan Wiger
- Re: RFC 138 (v1) Eliminate =~ operator. Mark-Jason Dominus
- Re: RFC 138 (v1) Eliminate =~ operator. Larry Wall
- Re: RFC 138 (v1) Eliminate =~ operator... Piers Cawley
- Re: RFC 138 (v1) Eliminate =~ operator. Tom Christiansen
- working mnemonic for =~ David L. Nicol