>>>With only some extra code they would have re-initialized the properties, without almost no impact on the performance. So, your idea that it's optimization is incorrect.
>
>First, I meant to write here: .. WITH almost no impact ...
>
>>Imagine initializing some Set(Path) like string of directories for the current running machine,
>>testing out a couple of hundred possible settings - that could take significant time.
>
>Not sure what your example is about. Do you mean this prop declaration?
>

cSetPath = set( 'path' )

>Should be fast enough, as it only demands for the retrieval of a purely textual string that has been created and validated beforehand.

Is/was partially contrived: Imagine a setup, where a number of definite sub-paths exists for
data, lookup data and code - be it development / testing / real data, several clients accessed from master program,
time series data split not vertically, but horizontally with different mechanisms access to guarantee speediest access for
more current data, finding data along possibly renamed 7 nonexisting logical paths or subst device names -
trying to access a nonexisting dir is relatively time-consuming.
Now a program might collect the currently existing paths for a given machine in an object,
having properties for code lookup (prg/vcx), internal structured data (frx), other internal, (jpg,bmp), output templates
(empty dbf/xml structures), import/export dirs and similar stuff.

Such a path object migth be utilized again by a myriad of services - if housed at app level at no perf cost,
but if designed as a sub-object in each service creating such an object again if not recurring to the "prototype"
with the cached results could result in markable slowdown.

Also if looking at vfp from a more generalized POV it is a scripting language:pseudo-compiled and interpreted,
thereby in runtime speed between 5 and 50 times slower in function call overhead and object creation.
Looking at typical C# and Java (compiling down to machine code from IL) code.
you see much more usage of throw-away objects because they are so much faster.
Best practice making sense in each environment -
From that angle I can fully understand the attempt to get vfp object creation "again" as fast as possible
(for instance the 500 odd elements of a large screen, mostly labels and text boxes, or even worse
on a big scrollable grid), as making object creation cost larger would create even more different patterns.

It is not only the evaluation of each property - the whole inheritance sequence would have to be walked again,
and the nice results published in the wiki might look differently for hundreds of objects
created from long inheritance lines vs. objects created from base classes: in the vfp/prototypal implementation
such difference is greatest in first instance, from that on nearly non-existant.

and yes - it should have been docced...

regards

thomas