Hi Koos

Markus Eggers proposition how to handle this is just the way that the commercial frameworks go. At least the ones I know off. ;)

You can alter your baseclasses, do bug fixing or add new fuctionality without any problem as long as you don't touch the existing interface of the classes.

Sounds easy, huh? It's all but that! Good interface conception in a framework is about the most difficult thing I can imagine in OOP. But as a rule of thumb, when ever you have to make a change of an object's interface in your framework that brakes existing code, you found an error you made earlier. Since this happens to me on a quite regular base, I followed the example of the commercial frameworks and added an intermediate object layer between my framework and my appclasses. At the beginning this is a simple subclassed one to one copy of the framework classes. This gives me at least the chance to settle those interface issues outside of the appclasses.

From time to time I nevertheless change the "version" of my framework to a newer and (I hope that at least ;) ) better one. Starting then with a new virgin intermediate layer of objects.

Every time I consider an app as finished I do a "codefreeze", that includes the framework and the intermediate classes as well. This way I'm always able to reset the whole development environment, just in case I'd have to do some quick changes.


HTH
Markus