It's worked well for a number of languages. Nim was mentioned, and D has done this for quite some time as well. http://dlang.org/spec/function.html#pseudo-member
A bit of background for the unified C++ call proposal
11–20 of 46 posts
Re: A bit of background for the unified C++ call proposal
#12>> 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…
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.
Re: A bit of background for the unified C++ call proposal
#13I have to agree with x.f(y).g(z) vs g(f(x,y),z)...jquery or d3.js would be terribly obtuse with the latter only.
But there are times when the functional notation is nicer than the OOish style. Really, having "both" is the right answer for libraries, although it might not always be possible. I suppose this proposal makes it easier for libs to do "both".
Also, can someone clarify for me, even though he mentions multimethods, these aren't really multimethods, right? Since f(x,y) becomes x.f(y), I'm assuming there is polymorphism involving the runtime type of x, but not y too, or is C++ getting true blue runtime multimethods?
Re: A bit of background for the unified C++ call proposal
#14I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c. I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascrip…
C++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically: old code should keep working possible, but they have the right to invent new features. The real difference is that C++ is feature-philic (new feature: want!), while Go is feature-phobic (new feature: avoid!)
Of course, if you want to make specific predictions about which features C++ or Go will adapt, then you need to look at details. For instance, Stroustrup tried hard in the early days to ensure that user-defined types are on equal footing with built-in types, while Go tried hard in the early days to make sure that very common foundational types are built in and have good support. Thus today the C++ standard library has two at least two distinct dictionary types, while Go has one built in to the language. (Someone who actually knows more about Go history than I do, please correct me if I'm wrong.) I tend to favor the C++ approach as more mathematically pleasing, but I can't deny that the Go approach leads to a simpler language. (The real question is: which one leads to better programs, and I suspect the answer is "it depends, on way too much stuff to even list".)
Re: A bit of background for the unified C++ call proposal
#15I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c. I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascrip…
In my language f.g(x) is syntactic sugar for g(f, x). Prefixing with the typename of f is not needed due to function overloading. (Which basically does the same thing I guess)
Re: A bit of background for the unified C++ call proposal
#16I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c. I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascrip…
In my language f.g(x) is syntactic sugar for g(f, x). Prefixing with the typename of f is not needed due to function overloading. (Which basically does the same thing I guess)
Interesting! Do you have separate symbol tables for functions and variables, then?
I've taken the major design decision that there's only one symbol table for variables, so every function is a functor. I'm not sure it's possible to reconcile this with function overloading (Go/Javascript don't)
EDIT: i suppose you could have a different symbol table for each variable type, incorporating function arities.
Re: A bit of background for the unified C++ call proposal
#17I'm not a fan of this. It strikes me as a masturbatory crusade. It's this kind of thing that ruins a language over time because people just wouldn't stop messing with it. Go find another language to perfect.
Re: A bit of background for the unified C++ call proposal
#18I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c. I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascrip…
C++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically: old code should keep working possible, but they have the right to invent new features. The real difference is that C++ is feature-philic (new feature: want!), while Go is feature-phobic (new feature: avoid!) Of course, if you want to make specific predictions…
[deleted]
Re: A bit of background for the unified C++ call proposal
#19I'm curious, would C++ ever consider categories like in ObjC? I.e. class extensions that unlike inheritance don't change the type. It kind of gets close with the unified call: if you have a call f(x,y) then either x.f(y) is matched or some f(x,y) that may be defined elsewhere. But still not the same as the ability to define a new x.g(y) for an existing class. (Edit: I can't even start to think what implications this…
Their proposal to allow x.f(y) to match a free function f(x, y) would obviate the need for anything like categories. I'm puzzled and saddened that this part of the proposal didn't go through.
[deleted]
Re: A bit of background for the unified C++ call proposal
#20In TXR Lisp, I provide a "referencing dot" syntax (http://www.nongnu.org/txr/txr-manpage.html#N-013775DB).
A dot between symbols or compound expressions, with no whitespace, translates to a qref form:
a.b.c.d -> (qref a b c d)
obj.child-obj.slot ;; slot access
obj.(fun arg1 arg2) ;; (call obj.fun obj arg1 arg2), obj evaluated once
It would complicate how function calls work. If global function f exists, x.(f y) still calls the one in x, unambiguously. for (f x y) to do that, the function lookup for f would first have to check that x is a struct object, and whether it has a slot called f, and then use it. Then otherwise fall back on behaving like a normal function call. That's just too much semantic cruft jammed into function calls.
The x.(f y) (f x y) equivalence only makes sense if you have a CLOS-like object system with generic functions that are separate from classes, so that f is a generic function named in the ordinary function namespace, which, when called, dispatches methods. Or a completely static language in which it is worked out at compile time whether f is an ordinary function or the member.