David,

>Why do you need a copy of the parameter object? You should be able to just keep passing the same one around. If you go copying and forking different versions of the parameter object around to different methods/functions I'd think it'd get hard to know what version of the parameter object is at any point. If the parameter object is not being written to by the destinations then there isn't much reason to not just use the one instance.

to get "passing by value" - in that framework you had to set properties like tablename, fieldname, nextobject, method2call, a specific aReturnvalue for multiple "parameters by reference" and so on. In "method delegating" the pattern of parameter usage is often partial parameter forwarding - which happened in the "working methods" quite often, for instance iterating over a set of tables or some fields in a table. Here the code was often 3 to 5 lines setting the values of the PO before the call, and 1 to 4 lines after the call, when written in "traditional style" with multiple parameters only the correct parameters would have bben written, perhaps once or twice as "by reference". Using the same PO was made difficult as some values in the PO-arrays were not guaranteed to stay stable across method call. It was LOUSY coding expirience, which made me quite hesitant to use parameter objects again - perhaps unwisely or to a too great extent, as that project had a tendency to be "out of balance".

Just too much code for "make do" cluttering the screen - methods grew too long as measured by line count (and grokability on first sight) but were still small if seen from the angle of "real function points". A shallow copy was one of my first routines after seeing the mess others had written (copying the needed properties from one PO to the next), but iterating over amembers() is also a lot of "running code" making the already existing hit in vfp for method or function call worse, so I'ld have welcomed a c-native internal iterating. But it made the methods more readable by far, as my personal rule was to use it whenever it replaced more than 4 property assignments on a newly created PO, with some leeway when needed in a large/tight loops for perf reasons.

regards

thomas