That said, yeah, it'd be nice if you could just make the assumption that if two objects point to the same memory, they're de facto identical...
I'm the author of the article.
The optimization here is that the check for plain-old symbol equality is happening without the need for a full ruby method dispatch. You can't make that assumption in the general case, because it's possible to override equality in Ruby, which then requires more work.
If you look at the full source code for the method in question, you'll see that it does special checks for Fixnums and Floats and Strings, then a check for the default object equality (i.e. does the comparison use rb_obj_equal?), then, finally, it falls back to a full method call.
Sure, but we aren't talking Ruby semantics here, we're talking C. I don't see why it's useful to still have a sym_equal identifier that's just an alias for rb_obj_equal.
That's exactly what #define does. It replaces all usages and gives the token the same identity as the other token. As a C programmer first and foremost, it looks reasonable to me.
First class functions are super useful in C, but I think it's pretty rare to rely on their identity at runtime. If you are doing that, also aliasing the same function by another name seems like a recipe for confusion.
`sym_equal` only makes 2 appearances in the whole codebase (to be bound to `Symbol#==` and `Symbol#===` in string.c), so there's not a whole lot of room for confusion.
Also, this is Ruby core! Smart people do what works and makes sense to them and don't spend a lot of time worrying about how clear it is to us unwashed masses.
It's perfectly valid to question using a macro to rename a function instead of just renaming calls, especially if the renamed function is only called twice. It also would've been more pragmatic to mention in the code that rb_obj_equal is being used due to an optimization in opt_eq_func, as it's not obvious.
There might be reasons for using a macro in this case, like wanting to underline the fact that symbols are being compared, but I strongly suspect the author was just focused on changing the implementation of sym_equal to be better, and didn't think of the option of throwing it away.
Exuberant ctags will find the #define that goes with sym_equal and make it quick to locate. Upon seeing that sym_equal is #define'd to rb_obj_equal, it will be clear that they're identical at the C level. It may not be obvious why it's a #define, but a cautious programmer would be on alert that changing it back to a separate function would likely have some kind of implications.
Perhaps the ideal solution would be a large refactor to make the whole system as self-explanatory and surprise-free as possible. While waiting for that, this #define looks like a reasonable and low-risk bug-fix.