5 ms·

And to straw man the OO way a little... newData = oldData.f().g().h().i().j().k() wont work by default unless you also happen to return the object after every

And to straw man the OO way a little... newData = oldData.f().g().h().i().j().k() wont work by default unless you also happen to return the object after every method (builder style) which looks weird and is not standard

imtringued 4y ago
I don't know what you mean. You can return a different type, the only constraint is that the methods don't return void and the subsequent method exists. This has nothing to do with the builder pattern.
- zelphirkalt 4y ago
  You still have to do work though, to ensure, that always some fitting object with the correct methods is returned, so that you can chain further. Functions by definition (as opposed to procedures) return something and as long as that is the correct thing or type of thing for the next function, all is fine.
  - stickfigure 4y ago
    You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.
    - zelphirkalt 4y ago
      What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned objects and you must return objects. In the function and data scenario, all that needs to be made sure is, that your functions have the return type, which the next function expects, otherwise it is a type error, regardless of whether the language complains or not. A function call chain implicitly assumes the types to be correct, otherwise you will likely run into an error. The difference is, that in the functions and data scenario, you already have functions, which take data of some type and return data of some type. You do not change them in any way, while on the other hand with objects and methods you need to change the methods, so that they do return some fitting objects.
      - LAC-Tech 4y ago
        There's no law stopping you returning a new object from a method outside the builder pattern. Immutable objects are a pretty old idea, smalltalk had select (map) methods that returned a whole new collection back in the 80s.
        stickfigure 4y ago
        ...and in fact most strings in OOP languages work like this: String next = original.substring(2);
singularity2001 4y ago
this has nothing to do with OO, function chaining depends on the output of the previous function regardless

imtringued 4y ago

I don't know what you mean. You can return a different type, the only constraint is that the methods don't return void and the subsequent method exists. This has nothing to do with the builder pattern.

zelphirkalt 4y ago
You still have to do work though, to ensure, that always some fitting object with the correct methods is returned, so that you can chain further. Functions by definition (as opposed to procedures) return something and as long as that is the correct thing or type of thing for the next function, all is fine.
- stickfigure 4y ago
  You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.
  - zelphirkalt 4y ago
    What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned objects and you must return objects. In the function and data scenario, all that needs to be made sure is, that your functions have the return type, which the next function expects, otherwise it is a type error, regardless of whether the language complains or not. A function call chain implicitly assumes the types to be correct, otherwise you will likely run into an error. The difference is, that in the functions and data scenario, you already have functions, which take data of some type and return data of some type. You do not change them in any way, while on the other hand with objects and methods you need to change the methods, so that they do return some fitting objects.
    - LAC-Tech 4y ago
      There's no law stopping you returning a new object from a method outside the builder pattern. Immutable objects are a pretty old idea, smalltalk had select (map) methods that returned a whole new collection back in the 80s.
      - stickfigure 4y ago
        ...and in fact most strings in OOP languages work like this: String next = original.substring(2);

singularity2001 4y ago

this has nothing to do with OO, function chaining depends on the output of the previous function regardless