4 ms·
A little confused about the authors decision to do operator overloading with the pipe operator rather than a function chaining interface for the functional bit.
by emcq 11y ago
A little confused about the authors decision to do operator overloading with the pipe operator rather than a function chaining interface for the functional bit. Wouldn't a function chaining interface be simpler and use less magic?
- vvanders 11y agoI think it approximates the pipe("|>") operator that you see in quite a few functional languages.
- restalis 11y agoAnd it is a poor choice to consider that in C++, because in here there already is a default non-compatible interpretation for their expression.
- CyberDildonics 11y agoIt depends on the context. The pipe in a data flow sense will be working on data structures, a bitwise or will need to work on two plain data types.
- restalis 11y agoYes, this was what I thought too. I understand where this "piping" of functions comes from and that it deemed to be a readability improvement (for *nix users at least), but it is unnecessary because like you've mentioned there already is a way of doing that in C++ and because at least for me the notation is a little bit confusing (as I'm inclined to read it as bitwise "OR" on function's addresses) and requires me to rewire my brain in a counter-C++ way!
- kbenson 11y agoDid you miss the part that said "[SYNTAX IS OPTIONAL !] Exact operator choice is up to You" ? Why criticize the author about a point they went out of their way to tell you was just a stand in for whatever syntax thought made a better choice?
- supernintendo 11y agoI'm guessing the perceived burden of debugging when dealing with function chaining (especially when you consider side effects from inheritance, it can get ugly). This is actually a case where operator overloading could allow for more maintainable code. Usually it's sort of a selfish design choice which provides marginal developer happiness and considerable ambiguity and bloat (in my opinion).
- Deregibus 11y agoYou're referring to something like? objA.funcA().funcB().funcC() I believe the issue is that it cannot easily be extended with new functionality since all of the methods must be members, whereas operator| can be defined as a free function which allows one to write new chainable functions without altering the base library. I agree that a function chaining syntax would be preferable. LINQ to Objects in .NET can do something like this because the language(s) support extension methods.