3 ms·

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 y

• 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);