David

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

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

A zip file containing all the files of the package would facilitate such sharing. This is done to support intra-programmer sharing. That is not really necessary. What is necessary is to be able to access the class at runtime!

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

I saw nothing about packaging in Ellen's 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.
>

"A package is purely conceptual. It does not exist at runtime!" A VCX is only a PHYSICAL 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.
>

I'm sorry Dave ;). You decided arbitrarily that these classes belong together. I see this as aggregating non-like classes. Everybody handles this differently and that is getting in my way alot.

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

cObject in cObject.vcx sounds right to me. I have a system that uses only Excel so your WordHelper would not help me. ;)

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

Agreed.

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

My recommended solution is not to refactor or repackage anything at all. By emulating the universe, I compose everything from atomic components. Since VFP has no logical/conceptual class library, I see little choice but to leave everything separated. The probability is I will make a mistake in my PHYSICAL packaging and have to refactor to fix it.

>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 was pretty sure that would be your position. You are not providing any examples of how it would get in your way. I used to do what you are doing! MaxFrame for a time had a set of classlibs that grew up over time. I wanted to create a COM DLL using one of the business objects. This DLL was huge because VFP pulled in all sorts of stuff. Drew thankfully refactored the PHYSICAL class packaging to reduce this bloating.

I know one aspect where this would get in your way. You would have to refactor alot to get to where I am. Conversely I'll never have to refactor again. Hopefully you'll see the light someday.

Thanks for taking the time.