Mike,

http://java.sun.com/j2se/1.5.0/docs/guide/lang/index.html - shows the high level packages that Java uses to bundle closely realted classes together.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/package-summary.html - details about one of the packages

http://fox.wikis.com/wc.dll?Wiki~BasicsOfModeling - some packaging discussion

http://fox.wikis.com/wc.dll?Wiki~UmlPackages - a definition from the UML perspective. Realize there both physical and logical packaging. In the case of a VCX it is a physical and can be a logical package.

I'm not sure how else to explain my concepts on packaging. To answer a question or two you posed in the Wiki topic. Yes all the first level subclasses of the VFP baseclasses should just be in one classlib. They all have very little that is done to them ie fixing a few quirks that you don't like about the VFP Baseclass, like Label.Autosize = .t., fixing backspace so it doesn't exit back out of the textbox. I also applied a single consistent error handling architecture at this level. I used cControl.vcx for these classes.

I also decided to bundle into cControl all of the next level subclasses like txtReadOnly that get basically get used in every app.

If the client app needs some new UI control classes (that don't merit reuse in other apps so they don't qualify to make it into cControl.vcx) I create one client level classlib for these classes.

Now when you are not talking about UI classes for example biz-objects they derive from my cObject class which is stored in cObject.vcx. I have some Office Automation helper classes like WordHelper and ExcelHelper they are stored in MSOffice.vcx. If an app doesn't use any Office automation (ie that package) is not used the MSOffice.vcx isn't put into the project. Now WordHelper and ExcelHelper are totally independent of each other, but I logically package them together because the probability is high that if I'm using Word in a solution Excel ends up getting involved too. Neither one is so huge that splitting them into two classlibs would make much app size difference, not compared to the handiness of having them right there together in the project manager.

What makes for bad packaging IMHO. AppA is being developed and ClassQ gets put into ClasslibX just because it handy, there's no real relation to any of the other classes in the classlib. This works fine while working on AppA.

Time passes and the client is real happy so they ask for AppB.. it needs to use ClassQ but nothing else from ClasslibX. If ClasslibX is added to the new project it brings along piles of stuff that is not needed (ie reports, prgs, forms and menus).

My recommended solution, promote (read that as move) ClassQ to a new classlib, use the new classlib in the new project, go back and update AppA.pjx to reflect the newly refactored packaging.

This refactoring/repackaging is something that evolves over time with experience, after a while a good developer gets a feel for "appropriate" packaging right from the start so there ends up being no required classlib refactoring.

Does that make it any clearer? I just believe that one class per classlib is overkill, and it would get in my way a lot. I also believe that all classes in one classlib seriously hurts reuse because of the excess things it brings into the Project₂ to Project_N.

>>I am sure of it. And it seemed to me a lot of your argument was based on poorly chosen classlib packaging.
>>
>Could you please expand on the term packaging? I have found nothing about classlib packaging. Classes "package" data and functionality (not necessarily code) into a finite object. IOW there is no difference between class packaging and class design. Grouping classes together into a classlib seems specific to FoxPro.