> You could "kinda" make it look like a "real" function, as has occasionally
> been suggested:
>
> match(STRING, PATTERN, FLAGS)
>
> But before that gets too much support, that has several problems.
> First, unless you have rather clever new context coercion prototypes
> of type regex (which would let us define split(), too, though)
I actually half-heartedly suggested this last night on a considerable
amount of beer :-), but ran into the same issues you mention. I do think
it's worth considering if we're dead-set on losing =~. It might also be
worth looking at Ed Mill's suggestion of putting the incoming string all
the way to the right. Then we could make it look like split and join:
match /pattern/flags, $string
subst /pattern/newpattern/flags, $string
The more I look at that, the more I like it. Very consistent with split
and join. You can now potentially match on @multiple_strings too.
Something else I threw out that maybe people didn't see was just using
=, ==, and !=:
$x == m/stuff/; # == replaces =~
$x != m/stuff/; # != replaces !~
$r = m/stuff/; # same as current
$r = ($x == m/stuff/); # == replaces =~
This would require redoing/overloading these, but that's an internals
quesion methinks.
The last alternative is to come up with a matching operator:
ma - "matches" (like eq)
nm - "not matches" (like ne)
$x ma /stuff/;
$x nm /stuff/;
But I think door #1 or #2 is better. I actually think I like the
function form alot.
-Nate
