4 ms·

This is indeed a clever and nice trick. That said, I doubt I will ever use it professionally. In fact, I would probably reject any changes in code review that

This is indeed a clever and nice trick. That said, I doubt I will ever use it professionally. In fact, I would probably reject any changes in code review that used this kind of trick.

smaudet 5y ago
> In fact, I would probably reject any changes in code review that used this kind of trick. Why not? Operator overloading (if used well) is invaluable to expressiveness, and at least IMO related to a strong type system. Abstract Algebra defines a whole formal nomenclature around defining operators such as add, subtract, etc., for _arbitrary structures_. Sure, it is complex, but good _engineering_ sometimes requires complexity. For real world examples, I would take numpy - its custom arrays are a bit jarring to newcomers at first, to be sure, but it is a damn _useful_ library. You can implement everything numpy does with "normal" functions, but you will end up with either unmaintainable nonsense or spaghetti code, e.g. in pseudo-code, it is clear what this does: Matrix Result = Matrix1^2+Matrix2^2 Versus: Matrix Matrix3 = Square(Matrix1); Matrix Matrix4 = Square(Matrix2); Matrix Result = Matrix1.Add(Matrix4); This code is intentionally incorrect - can you spot the difference immediately? It's trivially fixed, but only by running the processing stack in your head. This is a very common sort of error. People prefer Infix operators and then say that function soup is the only way to go... Note also that, while tests might catch that your code is wrong, you have to know what the code should be doing in order to spot that. It may even be easier to verify by using e.g automated proof verification.