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.
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:
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.