3 ms·
Also Bjarne Strostroup said that this (pun intended) was a mistake, since often there is no "most important" object. If you want to do generic programming, it'
by stabbles 3y ago
Also Bjarne Strostroup said that this (pun intended) was a mistake, since often there is no "most important" object.
If you want to do generic programming, it's much better to write f(a, b) instead of a.f(b).
Suppose I'm writing a generic algorithm that needs some function distance(A a, B b) for generic A and B. Distance is probably a commutative function, why would a.distance(b) be better than b.distance(a)? It's arbitrary.
Secondly, if functions are first-class citizens, and I don't "own" the types A and B, it's much easier to implement distance(A a, B b) myself than it is to extend the types A and B with a member function `distance`.
- commonlisp94 3y agoIt would make a huge difference if that style were used more in practice. OOP is just functions that are only polymorphic in 1 argument, when you want it on all of them.
- coldtea 3y agoMultiple dispatch for the win...
- bobboies 3y agoAlso see: Effective C++ (by Scott Meyers) Item 23: “Prefer non-member non-friend functions to member functions. Doing so increases encapsulation, packaging flexibility, and functional extensibility.” The text has a lot more detail but that’s a brief summary. Folks just need to read the literature then this sort of knowledge would be in common use. One downside of language evolution is a lot of people focusing on new language features, etc, but then some of this older, important knowledge gets skipped over.
- iraqmtpizza 3y agois it not apparent that a.distance(b) and b.distance(a) should both exist? if they don't, the API is poorly designed