3 ms·
The real meat of this post is: > "No more class, no more worrying about const, no more worrying about memoization (it becomes the caller’s problem, for better
by jonnycat 6y ago
The real meat of this post is:
> "No more class, no more worrying about const, no more worrying about memoization (it becomes the caller’s problem, for better or worse)."
By making the memoization the "caller's problem", this refactor has completely changed what the code does, for the sake of calling out "an OO antipattern".
Yes, there are of course other ways to implement some form of memoization or caching without classes. And without knowing the particular use case, it's impossible to form an opinion on whether it should be the caller's responsibility or not. But I find it unconvincing to make an argument for "here's a better way to solve problem X" and then present a solution for solving problem Y.
- Twisol 6y agoThe memoization capability only disappears in the very last step, which I would argue is not the meat of the post. Up to that point, very valuable refactorings and simplications have been applied. One could very well have replaced the final transformation with a factoring out of the algorithm into a free function, which the constructor merely calls and caches the result of, without meaningfully changing the point of the post. (In fact, that would call out the memoization capability as an orthogonal aspect even more strongly, since you could reuse the same construction for memoizing other free functions.)