3 ms·

Can you explain why you feel this way? I personally hate named and optional parameters, as they inevitably seem to drastically inflate the complexity of the fun

Can you explain why you feel this way? I personally hate named and optional parameters, as they inevitably seem to drastically inflate the complexity of the function. I would much rather deal with a builder class that encapsulates doing something over calling a method with fifteen parameters, half of which are optional. And god forbid you have optional bool args! If I need to call a monster like that repeatedly, I'm likely to make my own wrapper that's simpler anyway - so why not start out that way.

musicale 4y ago
One thing I like is that: foo(a=1, b=2, c=3) is shorter (and, I would argue, clearer) than foo().a(1).b(2).c(3) and requires only one method declaration and one method call. Also for constructors you don't have to worry about partial or out-of-order initialization. Is the above the same as foo().c(3).b(2).a(1) ?? What if one call involves opening a file or allocating some resource that is used by another call? One nice thing that method chaining does give you is being able to differentiate external and internal parameter names. Swift (for example) supports this with argument labels for doing things like insert(something, into: list, at: position) rather than having to use the variable name: insert(something, list:list, pos:position) Of course I wish that Swift supported ObjC/Smalltalk-like syntax so you could just do insert a into: list at: position Note SwiftUI actually uses method chaining for some reason. It's OK but I would have been fine with named parameters. But I do like Smalltalk's method chaining/cascade syntax: robot walkForward; wave; sitDown.