2 ms·

His book on refactoring was one of the most revelatory programming books I've ever read, and was a major influence on how I program. I'm sure if I re-read it to

His book on refactoring was one of the most revelatory programming books I've ever read, and was a major influence on how I program. I'm sure if I re-read it today I'd raise a few eyebrows at sections, but it's 17 years old now. I've no idea how good it is now, given how much we've moved on, but it was very good back in the day. He's had some real hits. But I must admit, I find this article a bit silly. He's had some stinkers too. Worse still, this is an obvious problem because the solution's been in other languages for decades, overloading equivalence, it's just not in javascript. It's just not a common programming problem outside of certain domains. And, he knows it. So I really do not understand the point of that post. There was a time when every single one of the "learn .Net 1.0 in 28 days" books would have at least a paragraph about overloading Equals and GetHashCode. This is from 2005, for example, and even uses the same example: https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).aspx https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).a... The blog post seems a decade too late.

wwwigham 10y ago
IMO, The issue with this article is that it conflated a desire for immutable record types (as you'd see in a functional language) with something which requires equivalence overloading in a language which does not support them (as you'd find in a heavy OO language). I think while he presented _A_ solution to the specific issue he encountered (wanting to compare algebraic types as cohesive units in Java), it is not the _best_ general solution to the issue - in fact, it's really not the best solution in any language without built-in record types, as it can lead to costly hidden comparison times and unneeded memory growth (which most design patterns I would say should discourage this kind of hidden performance issue). This is a data structure problem which should be attacked much like how a compiler implementer would attack it - by being lazy and doing at little work as possible. Instead of making similar objects appear equivalent - make identical objects be references to the same object! Since we already decided to let records be immutable, it actually turns out quite nicely in JS, as I have written elsewhere - and I'm confident that the same cached-reference/object interning strategy could be used in Java, too.

wwwigham 10y ago

IMO, The issue with this article is that it conflated a desire for immutable record types (as you'd see in a functional language) with something which requires equivalence overloading in a language which does not support them (as you'd find in a heavy OO language). I think while he presented _A_ solution to the specific issue he encountered (wanting to compare algebraic types as cohesive units in Java), it is not the _best_ general solution to the issue - in fact, it's really not the best solution in any language without built-in record types, as it can lead to costly hidden comparison times and unneeded memory growth (which most design patterns I would say should discourage this kind of hidden performance issue). This is a data structure problem which should be attacked much like how a compiler implementer would attack it - by being lazy and doing at little work as possible. Instead of making similar objects appear equivalent - make identical objects be references to the same object! Since we already decided to let records be immutable, it actually turns out quite nicely in JS, as I have written elsewhere - and I'm confident that the same cached-reference/object interning strategy could be used in Java, too.