>>I use it basically to make dynamic changes to DTOs , so Vfp can do real message based communications with ease.
>>
>>Configuration objects, parameter objects can benefit too; but I'm rounding a definitive spec to get Intellisense to work with object constructor functions that make use of _()
>
>Be careful with many additon to parameter objects - that can really hurt performance.
>
>Dozen years ago I was given a design already using a *very heavy* parameter object (including a couple of array properties) which created a serious brake in performance as parameter object often had to be cloned.
>
>Ended up with a streamlined version, but still had to create an object pool for them as always creating/destroying was to expensive.
>Just keep them as naked as possible ;-)

Yeah this is one thing that VFP is not so good at. A few years back I built a Web framework (WebForms for VFP basically) that created massive amounts of objects and it ended up getting really slow on large forms because as the object count goes up VFP starts slowing down exponentially. Releasing references as soon as possible was a key to getting that code to work effectively. (there were other issues there - namely circular references that would hang and leak memory eventually unless explicitly cleaned up that was problematic).

This dynamic class is very user friendly but it definitely introduces overhead - one extra reference at minimum plus the overhead of the accessor for each and every call that references the dynamic object. I think for any 'system level' code that is built into a framework or other place where it runs frequently in a tight loop you'll want to stick to the raw processing of using ADDPROPERTY() under tight program control. But for user level code and things like returning what essentially is tuples this is an awesome solution that makes for clean looking code.

+++ Rick ---