>Hi Fabio,
>>I Hope that you can understand this english.
>I am not too certain on all points, but I'll ask my way along.
>
>>If ( like example ),
>>running an application, the app use 100000 Classes ( not objects !!! classes ),
>
>First question: are those 100000 classes distinct classes in the sense that you createobject() from *them* or are all the parentclasses of the last class to instantiate from included in this number ?
>
>If they are distinct classes: vfp tends to perform best if all dynamically accessed parts are within "usual" parameters. As you know vfp performance degrades more than linear if you use too many objects, open too many tables, have too many indices and so on. 100000 classes would make me think hard on possible alternative approaches<g>.
>
>Is it perhaps possible to reduce the class number via dynamic configuration of objects to get at a smaller number of basic building blocks ? Use more aggregation, less inheritance ? Probably the best approach, if possible for your task, and according to OOP principle. Since the objects configure themselves dynamically, you would not have 100000 class templates, but still get the same number of objects with differing behaviour.
>
>Or can you offload some of the class driven functionality to table based handling ? Less OOP, but using vfp's strength.
>
>Or if you have mostly similar classes with different behaviour in polymorph methods, how about implementing a "classless solution" employing your own variant of name mangling to find the correct function and always give more general objects as first parameter ? This way you get nearly object method "functionality" in a function based scenario - and you don't have vfp's unneccesary "class baggage" taking up memory. The implicit "this" as first parameter is not unusual, and even on the java front there are some discussions about "non-class-based" functionality.
>
>[Since I know nothing of your app please excuse me if i am totally off base in my questions: you probably checked at least some of these possibilities]
>
>>but medium they are in use 1000 classes only ( for to maintain on live 5000 objects ),
>>the VFP's VM maintain in memory all the 100000 classes and therefore must make I a CLEAR CLASS,
>>or the VM manage this automatically ( and then a Class can to be reloaded at a not deterministic time )?
>
>As far as I remember [mostly from reading] there is a difference in the caching done to objects born via createobject() vs. newobject(). When you are creating lots of objects from the same class, createobject() get faster due to having located and cached the necessary records in the relevant libraries, whereas newobject() shouldn't do this.
>Update:Sorry, wrong memory: NewObject caches as well...
>
>Hope I expressed myself not too vague: if anything is unclear, don't hesitate to ask.
>
>regards
>
>thomas

Hi Thomas,

I have no problem with class design, and i write 100000 like a big number only.
Not task that a true application can have 100000 different classes and, as you say, a combinatorial design facilitates this a lot.
My problem is different:
VFP eliminates, automatically , one definition of the code category from the memory or not?
If VFP don't release a definition of the class from the memory, therefore I must control this with CLEAR CLASS (fixed on VFP9) and I do not have problems
(really this is not very simple because VFP, afaik, does not have one FUNCTION that returns the resources in the memory).
But!, if, when the memory resources are to the limit, VFP eliminates a free definition of the class from the memory, then some problems exist.

Fabio