Re: named captures assigning to local variables

Gary Wright wrote:
> It isn't too hard to stuff matches into local vars
> as it is:
> 
> _, first, second = */(.+)\W+(.+)/.match("alpha beta")
> 
> vs the proposed
> 
> /(?<first>.+)\W+(?<second>.+)/ = "alpha beta"
> 
> and the first approach has the added benefit of
> working if you change the regular expression to
> a variable/constant:
> 
> _, first, second = *TWO_WORDS.match(text)

I agree here...the magic assignment doesn't seem to buy much over just 
doing a normal masgn.

> If I've got regular expressions that are sufficiently
> complicated that I want to name the captures, I'm not sure I
> will want them buried in code as a literal expression.  I'd
> probably define a constant for the RE just as I would for
> any 'magic' numeric constant--at which point the local
> variable assignment, as proposed, would be superfluous.

I could see it actually getting in the way, in fact, since now I have to 
track both "declared" local variables and named captures in a regexp 
(which are far less obvious).

I imagine this would also complicate parsetree/ripper and tools that 
depend on them since the variables assigned by the regex would have to 
fit *somewhere* in the tree.

> It would be even more awkward if the named captures in a
> non-literal RE magically instantiated local variables.

This would also be really bad from a performance perspective, since it 
would mean all scopes that use regex would have to have growable 
variable stores (and potentially dictionary-based variable 
stores...ouch!). I don't see any way this would be feasible if the local 
variables didn't also get into the Ruby AST somehow.

I've said it before...new features are great, and Ruby should be evolved 
without a constant, nagging concern for implementation difficulty. But 
it would be unwise to introduce *any* feature that automatically has 
serious performance implications.

> One final thought--I'm not sure I'd bother with the local
> variables anyway if I can treat the match data object
> like a hash:
> 
> match = TWO_WORDS.match(text)
> Customer.find_by_lastname(match[:second]))

I prefer this over almost all other options; it's more explicit, less 
magic (than implicit assignment), and less syntax (than explicit 
assignment). And it breaks exactly zero expectations about how regex are 
supposed to work, since it only adds additional behavior upon what 
already exists.

- Charlie