>>>>Got it. Alternate solutions are always good to have. You never know which solution will work out best for any given situation. Any working solution is a good solution.
>>>
>>>Actually, I like Arnon's suggestion - the calling routine doesn't have to prepare anything. It calls a function and receives results in an object. It just seems a little cleaner - a function should not modify its parameters, but it should return values, right? So it does, this way.
>>>
>>>If we wanted to have something done to an object, wouldn't it be more natural to tell the object to do with itself - it should have the means (aka methods) to do that.
>>
>>True. But you could also pass this object around to different other objects/functions to manipulate. There's nothing that prevents the parameter object from having it's own methods, too.
>
>Actually, we have more things available than we need - and we can develop some really dirty techniques here, which may be like hell to document. Imagine an object, having its own methods, passed to a function, which does some of its things with the object, plus calls some of the object's methods, and some of these methods, in turn, call functions passing This as a parameter... and the ground and minced object is finally returned as a result from the function. We can achieve many things this way, but... it's so self-documenting, that it just needs a couple of GOTO statements to fit the bill.
>
>That's why I liked Arnon's suggestion - it just seams cleaner.

Any kind of "power tool" can create far more damage than a "simple tool" can create if used improperly. The skill (and knowledge!) to apply the proper tool to the job is an art in itself.