>Mike
>
>>Please give an example of a logical/virtual not physical package in VFP.
>
>A logical package is just a collection of related things. You can have an OrderEntry package that is comprised of all the classlibs, forms, prgs, reports and menus that pertain to that subsystem of the app. You can have a package the aggregates all of the bizobjs. If your database is comprised of 200 tables you can put logical groups of tables into a package. Packages are sort of arbitrary, they can be whatever you want them to be to help someone design/understand/document/deploy/whateverelse a system.
>

So IOW there is no such animal in VFP? The logical package only exists in the mind of the developer? If so, then I can produce a list of the contents of a "package" and the physical arrangement of the components isn't significant?


>>>>Similarly if there was a huge piece of code, it would be more efficient to have multiple smaller pieces of code for multiple developers to work on simultaneously, right?
>>>
>>>Huge pieces of code are no longer good design. Classes are supposed to be relatively small amounts of code.
>>>
>>
>>OK, so then how is a large classlib a good thing?
>
>Mike I'm not saying either huge or large is a good thing. Appropriately and convienently sized is what I call a good thing. There is no magic number for how many classes should be in a classlib.

I still think we're saying similar things. We both tend to more granular, I'm just further along the spectrum than you. Do you work in other people's projects much? I started on a project where I'm working now. We needed a particular class that MaxFrame happened to have. Ended up not being able to use that class without copying it out of the classlib because it tried to bring in most of MaxFrame. Drew thought he was grouping things properly AT THE TIME. ;) He ended up inadverdently causing refactoring. Further, if I get a new version of that class I have to remember to copy it, yecch! ;)

It seems that VSS integration is the only drawback to my idea.

I think I'm doing a bad job explaining myself and that's causing problems.

I'm trying to see your perspective. In doing so, I'm finding ways to better express my perspective. Let's suppose classes are blueprints and they become instances only at runtime. If I want to do a tuneup on my car, I'll have instances of spark plugs, a fuel filter, and spark plug wires.

Do you believe there is a single place where the blueprints for these parts are kept together? If I only used Bosch parts, it may be said that the blueprints are housed in the Bosch classlib. More importantly, do you want to buy all of the Bosch blueprints just because you bought a Bosch spark plug?

I believe I may find a tune up kit - but that is a collection of instances, not a collection of the blueprints.

Conceptually, I can group the blueprints together in my mind. There is no physical collection of them nor is there a need for such a collection for me to perform the tuneup.

Functional cohesion (the best form of cohesion) means (to me) that the spark plug serves one function in the system. The methods in the spark plug must support that one function.

Is the tuneup a function point in the car? Nope. I believe there is no need for a tuneup classlib since the collection of the parts serves no purpose in the car. Each part serves a purpose, but an assemblage that welds the spark plugs, the wires and the fuel filter together serves no purpose.

I think there should be a way to conceptually group the classes/blueprints together. There should not be a way to physically group the classes/blueprints together.

There should be a way to physically group the instances together. There is! It's called an EXE/DLL. To me these are analogous of the car.

Do you see that perspective?