>If my path can be of any help then, let me tell you this: Pragmatism when it comes to OOP is _the_ key. I do not believe that you can model a framework in advance. I couldn't in any case. You refine it with every application, because you tested it.

That's the way it worked in FPD, and that's what I plan for VFP, with the advantage of local subclasses most (or all) of framework classes for each app. These are the candidates to be induced back into the framework (or just some of their features) if they play well in production.

> Contrary to what we are (were?) used, if you framework does not work right, and you do not know that in advance, you are in trouble, because you cannot change parents. Well technically you can of course, but practically you cannot if you do not want to end up like that dog trying to catch it's own tail.

:) We should invent twin parents. That's what I'm trying to propose, by using a local subclass, which can be safely reset to default if it's wrong - but it surely won't help if a class design goes astray too far. Anyway, I've probably taken the wrong approach, by not finishing design of a class until it performs well in a live app, but, then, it's pragmatism :). The theory comes later, if ever.

>Bad objects is the worst that can happen to you. And the only good objects I know are objects that work in production.
>
>Do not tell me I did not warn you. :)

If we kept warning each other about every theoretical cul-de-sac, we'd end in a practical one. I should warn myself (which I surely do - there's a wall quite near my head, to bang it on if I forget), because looking around for "who didn't warn me" is illusory. "Who forgot to turn off the light?" - "Everybody".

And, another thing, having all this theory and strategy settled down with ourselves, and complying to it, is not enough. There are the users. We have a proverb here - "only a good user is a good user".