3 ms·

It's not a replacement for method chaining, and can't even be used for that purpose. It's for rearranging the relative position of a function's arguments. In ps

It's not a replacement for method chaining, and can't even be used for that purpose. It's for rearranging the relative position of a function's arguments. In pseudocode, it's defined like: x |> f ->. f(x) So, applying that, it would let you transform something like exclaim(capitalize(doubleSay("hello"))) to your first example. But it can't do anything with the 2nd example, because those are not functions with arguments, they're all 0-arity method calls. More generally, I don't think this operator makes much sense in a language that's mostly object-oriented. I made one in Scala a while back and toyed with it, but even there it's pretty useless because the libraries follow a very object-oriented coding style. I've really only seen it shine in a language that has strong ML roots and tends to stick to them.

tom_mellior 9y ago
> those are not functions with arguments, they're all 0-arity method calls In other words, they are 1-argument function calls. The "this"/"self" parameter is implicit in many languages, but otherwise it's not different from a normal function parameter. In the "method chaining" version of the example, each method call returns a (reference to) a temporary object which is passed as the next method call's "this" parameter.
- bunderbunder 9y ago
  In most languages, that's an implementation detail that is hidden by the compiler, and not a part of the semantics of the language itself. More specifically, if the language won't allow me to do both: foo.method(x) and method(foo, x) and have them behave the same way, then I submit that, regardless of what's going on behind the curtain, a n-arity method is not really the same thing as a (n+1)-arity function in that language.
  - kd5bjo 9y ago
    Python is pretty close to this. Assuming that foo is an instance of class Bar, foo.method(x) Is equivalent[1] to Bar.method(foo, x) [1] in the absence of monkey patching on foo

tom_mellior 9y ago

> those are not functions with arguments, they're all 0-arity method calls In other words, they are 1-argument function calls. The "this"/"self" parameter is implicit in many languages, but otherwise it's not different from a normal function parameter. In the "method chaining" version of the example, each method call returns a (reference to) a temporary object which is passed as the next method call's "this" parameter.

bunderbunder 9y ago
In most languages, that's an implementation detail that is hidden by the compiler, and not a part of the semantics of the language itself. More specifically, if the language won't allow me to do both: foo.method(x) and method(foo, x) and have them behave the same way, then I submit that, regardless of what's going on behind the curtain, a n-arity method is not really the same thing as a (n+1)-arity function in that language.
- kd5bjo 9y ago
  Python is pretty close to this. Assuming that foo is an instance of class Bar, foo.method(x) Is equivalent[1] to Bar.method(foo, x) [1] in the absence of monkey patching on foo