Hi Jim
>I think we're arguing the same side of the argument here. My example was an attempt to demonstrate a need where performing a single task could logically require multiple results.

We are partially for sure, and perhaps I am overinterpreting other things <g>.

>Isn't this exactly what you're saying is appropriate on occasion?
My example is for a rather highly abstracted business call "get the regression parameters". This call (including the parameter object as method signature ) could probably be used to cross tier levels. The parameter object could be seen as a special "business object".

Inside the tiers is the place I'ld go for lean and mean, because calling many times across tiers is not something to strive for. Define the work for each logical component and let it work, and return the finished result to the calling tier - dont call often "down", possibly across several layers, to get one result. If you are doing this (and why else strive for mean function overhead between tiers): that is what I meant with possibly rechecking your approach, but I could have misinterpreted your writings.

OTOH, using parameter objects has some drawbacks as well. Mostly the missing machine level coded "object clone" for use cases where you want to create a "local" copy of your given parameters. And sometimes you get junior programmers only copying the object reference to make a "backup" - arrays with their acopy() are nicer in this regard, but not as self-explanatory.

regards

thomas