Bundling up arguments into an object can be a great thing. The question for me is always- is the object mutable? If the object isn’t mutable, I don’t really care if you pass it around instead of a few arguments. If it is mutable, I’d rarely take it as an argument to a function. Who knows what the function will do when it is passed a mutable instance? As I think I said in the article, I only pass mutable instances into functions (in general) with internal/inline methods/functions.

I’m more interested in where you draw the line, though. At some point, wrapping up the function arguments into a single structure affords better properties than simply passing in an awful lot of arguments piecemeal. Lots of arguments are horrible: potentially messing up the order, involving an awful lot of boilerplate for named args, or just unpacking the Foo into named arguments (why aren’t you passing in the whole thing, at this point?). Yes, you should probably split the function up if it requires that much *stuff*, but something still needs to unpack the stuff and dispatch it to your small functions. Does the function orchestrating these take a Foo?

To my mind, this becomes a bit of a wobbly issue. It’s not so much a case of how many members frob needs to access, but whether the function notionally operates on Foos or a collection of subFooian values. Maybe the structure of Foo itself carries information. And this kind of argument extends to methods… to abuse your example, Foo.frob doesn’t need to be on Foo, and if it has any useful behaviour in a universe absent Foos it probably shouldn’t, but in many cases such offending functions are actually methods.

Part of the problem is that OO tends to leave us with the idea that we should only be passing objects around and using methods, when frequently operating on simple structures with independent functions is the Right Thing in my opinion.