>
>"I'd" stands for "I would" - I mean I'm not deeply into any app yet, so this is all just a plan, so far. Well, one of the first things I've learned of OOP is that's it's 70% planning, and the rest is coding & testing. So, I've taken the slow pace. Anyway, this was the way we operate in FPD, and I'm deeply in self-compatibility issues for many years now, and once we finally migrate to VFP in production, it will get deeper. Knowing the usual culprits in advance helps a lot :).
>

Well Dragan,

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. 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.

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. :)

Marc