4 ms·

>> I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would ser

by lholden 11y ago

>> I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think the concern is that a class "owns" its methods either directly or through inheritance. Therefor, the interface is expressed by this namespace and it can't be "invaded" or modified. From that perspective, having f(x,y) being callable as x.f(y) would be a violation of your interface. But... the dot syntax does not make an interface, and neither does it make "object oriented programming". It implies that "f" is a specialized function for somehow applying "y" to "x". If you have a generic "f" that can be compiled to a specialized "f" for your type... you are just adding composability to your language. That's a good thing! Calling "f" as x.f(y) in this case makes a lot of sense. It's just another specialized function for applying "y" to "x".

davidnc 11y ago
The paper "Unified Call Concerns" (linked at the end of the post) describes the issue in a bit more detail: you might write f(X x, Y y), knowing that X doesn't have a member function f, and call it with x.f(y). If a new version of the library extends X's API to include the member f(Y y), your code will suddenly start calling the member instead of the original non-member function. As he mentions in that paper, this isn't likely to be a common issue, so I'm with the general consensus that it seems unfortunate that the feature wasn't adopted.
DrDimension 11y ago
I'm going to have to pose an educated disagreement. According to the classic C++ article, "What's in a class?" by Herb Sutter (http://www.gotw.ca/publications/mill02.htm http://www.gotw.ca/publications/mill02.htm) - The Interface Principle suggests - For a class X, all functions, including free functions, that both (a) "mention" X, and (b) are "supplied with" X are logically part of X, because they form part of the interface of X. So yes, f(x) is part of x's interface in C++, and has been considered to be so for a long time.
- deleted 11y ago
  [deleted]
- lholden 11y ago
  "I'm going to have to pose an educated disagreement." A little awkward to read in response to my comment. An educated disagreement to what? I guess you are disagreeing with their argument? I agree with your comment. Or maybe it's a disagreement with what I think their argument is? This is why I am asking. :)

by lholden 11y ago

davidnc 11y ago

The paper "Unified Call Concerns" (linked at the end of the post) describes the issue in a bit more detail: you might write f(X x, Y y), knowing that X doesn't have a member function f, and call it with x.f(y). If a new version of the library extends X's API to include the member f(Y y), your code will suddenly start calling the member instead of the original non-member function. As he mentions in that paper, this isn't likely to be a common issue, so I'm with the general consensus that it seems unfortunate that the feature wasn't adopted.

DrDimension 11y ago

I'm going to have to pose an educated disagreement. According to the classic C++ article, "What's in a class?" by Herb Sutter (http://www.gotw.ca/publications/mill02.htm http://www.gotw.ca/publications/mill02.htm) - The Interface Principle suggests - For a class X, all functions, including free functions, that both (a) "mention" X, and (b) are "supplied with" X are logically part of X, because they form part of the interface of X. So yes, f(x) is part of x's interface in C++, and has been considered to be so for a long time.

deleted 11y ago
[deleted]
lholden 11y ago
"I'm going to have to pose an educated disagreement." A little awkward to read in response to my comment. An educated disagreement to what? I guess you are disagreeing with their argument? I agree with your comment. Or maybe it's a disagreement with what I think their argument is? This is why I am asking. :)