>Personally, I would like to see the default abstract factory support two files. It would look in aclasses.dbf first, and if it didn't find the key there, it would look in classes.dbf. This would solve two problems...
>
>1. You wouldn't have to manually maintain ap level copies of classes.dbf, all you would do would be to duplicate a key that you wanted to override into aclasses.dbf.
>
>2. You wouldn't need a 2nd instance of the AbstractFactory to use for your own uses... since be default goApp.oFactory would look in aclasses first, then in classes.
>
>What do you think?

I think I like this idea BOb,
But this would be assuming I implement AbstractFactory for every app I develop. You (or Kevin) would know better than I do how much overhead would be involved if this approach was used, and then you create a fairly simple app that doesn't need to substitute anything? Also, I had played around with adding a field to my app copy of classes.dbf to flag records specific to the app to make possible maintenance easier... but I think I like this ideal of aclasses much better.