Add MasgnNode class for masgn nodes

[dvandersluis]

Follows #201. I actually ended up needing masgn to have its own class with expression defined in order to do the refactoring I wanted to, so this adds it.

Because masgn nodes are more involved than the other assignment types, this class has a different interface than the other assignments, except for expression which works the same. Rather than name that the other assignment classes have, MasgnNode has names (since there will inherently be more than one). It also is able to handle nested mlhses.

[dvandersluis]

Sorry I missed this in my previous PR @marcandre 😅 🙌

[marcandre]

masgn is complicated, isn't it? 😅

PR looks like a good start, but you seem to have overlooked 2 important cases: foo.bar, foo[:baz], ... = ....
Please describe results of your proposed methods and add tests.

Also:

• each_descendant should only be used on the first child. Please add a test for x, y = 1, z+=2 for example. Even then, some corner cases could be problematic: foo[x+=1], bar = ...

• I doubt each_assignment is necessary. Performance of enumerators is typically quite poor, especially for short lists

[dvandersluis]

I knew there were things I wasn't thinking of, thanks @marcandre I'll fix up for those cases!

[dvandersluis]

@marcandre updated now.

I have now introduced a MlhsNode as well, which the assignments logic has been moved to (and each_assignment has been removed). MlhsNode#assignments takes care of finding nested assignments (in splats or other mlhs nodes), and also now returns send nodes to cover your edge cases. I also have a tests covering casgn nodes now, which were previously missing.

MasgnNode#names is now able to handle send nodes as well (by just returning the source, I don't think there's a better solution for foo.bar or foo[:bar], etc.).

I also added values and array? to make it easier to process the values in the expression.

For symmetry, MasgnNode now has lhs (returns the mlhs node) and rhs (alias of expression) methods.

Please let me know your thoughts!

[dvandersluis]

The "modern" spec was failing on indexasgn nodes so that's handled now too.

[dvandersluis]

@marcandre it's been a long time but I updated this PR and tried to address your concerns/simplify some things.

[marcandre]

That's great @dvandersluis , good work.

So a decision remains as to what we return for the LHS in the different cases:

• setting a variable a => :a (probably)
• calling []= => ?
• calling a= => ?

[dvandersluis]

I think for simplicity with names, if a LHS value is a send node, using method_name unadulterated would suffice given your suggestions.

a, b.c, d[e] = z => [:a, :c=, :[]=]

Is this what you had in mind @marcandre?

[marcandre]

I think for simplicity with names, if a LHS value is a send node, using method_name unadulterated would suffice given your suggestions.

a, b.c, d[e] = z => [:a, :c=, :[]=]

Is this what you had in mind @marcandre?

Yes, I agree that's probably best 👍

[dvandersluis]

Updated #names and #expression tests as per review.

[marcandre]

I think it would be worth explaining the subtle difference between expression and values, in particular that [1, 2] vs 1, 2 (which expression considers the same but values doesn't)

[marcandre]

So quick! A bit of extra doc and this is good to go. It's 2am here in Barcelona, so I'll look at it tomorrow 😅

[dvandersluis]

Thanks as always for your quick reviews @marcandre! I updated with some more documentation on expression and values; let me know if there is more you want there.

[marcandre]

Very nice, thank you ❤️

[marcandre]

Released v1.13.0