Yes, I see. That makes sense. Scala inherits a lot of baggage from Java. I understand there are huge costs of re-inventing the wheel simply because some Java baggage is not elegant.
My use case was that two of my methods (the same method in two different classes) is very large, containing a long list of reduction/simplification rules (sort of like algebraic reduction/simplification). In each case this is implemented as a list of 0-ary anonymous functions which each look at this
to decide whether it is something that simplifies, and if so returns a simpler form.
I was playing with refactoring this code, because a list of simplification rules can easily be thought of as data, rather than as code—but it is data which is parameterized by this
. I wanted to write a function which takes this
as argument, that way I could refactor simply by cut-and-paste. But now I see I need to cut-paste and replace references to this
with another variable name.
Side note: when refactoring it is often not clear whether it is a good idea. You have to just do it and look at the results, and decide is the code now better or worse. Highly composable code is more easily refactorable, because you can move the code around easily without adding lots of boiler plating.