Mike,

>So IOW there is no such animal in VFP?

No native logical packages exist in VFP.

>The logical package only exists in the mind of the developer?

Or the documentor, or the user, or the tester, or the WhoeverElseNeedsToUnderstandTheSystem from a bigger perspective.

>If so, then I can produce a list of the contents of a "package" and the physical arrangement of the components isn't significant?

Yes, for the most part physical packaging has no relevance to logical packaging.

>I still think we're saying similar things. We both tend to more granular, I'm just further along the spectrum than you.

Yes, in the spectrum I posted way back when, you are at the far left end and I'm to the right of 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! ;)

Yes, the place I work now had a quite horrid classlib structure philosophy, lots of cases where trying to reuse one smallish class causes a huge amount of totally unrelated classlibs to be sucked into the project. Thanks to the VFP Team for the ubiquitous Exclude item on the project menu we can at least keep from bloating the exe.

With the newer stuff I've been able to convince them to architect much better structuring which makes the newer apps better.. but as much as I'd like to go back and refactor some of the older libraries it would mean that too many end-client apps would need to be touched and it's cost prohibitive.

>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 understand your position, I just don't agree with it. *s*

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

I'd say that a tuneup kit would make a good logical package.

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

Let me give you an example of the classlib I'm currently working on (indent level indicates subclassing):

cObject - cObject.vcx
   cCOMable - cObject.vcx
      nvoDataAccess - nvoDataAccess.vcx
         nvoFTP - nvoFTP.vcx
   cFTPBase - nvoFTP.vcx
      cFTP - nvoFTP.vcx
      cSecureFTP - nvoFTP.vcx

nvoFTP is the class that will be instantiated and used by the developers in their code. It requires access to SQL server tables so it is derived from the class that provides that functionality. It handles the "big picture" aspect that is common to how our applications need to move files around betweeen ourselves and our clients. nvoFTP will instantiate either a cFTP or cSecureFTP object to provide the grunt work of actually using the API calls to carry out the FTP transfer. cFTPBase is an abstract class, it does have a pile of code (maybe a dozen methods a this point) in it though but will never be directly instanced.

All 4 of these FTP classes are bundled into the same vcx. nvoFTP can not be used without cFTP or cSecureFTP so it makes sense to us to have all of this in one physical package. Now you say but an instance is either going to be doing plain ftp or secure ftp so why drag the other along when you don't need it? I'd counter with they are both fairly lightweight classes the size penalty in the exe is insignificant.

Could they have been put into 4 separate classlibs? Yeah, but that just seems like overkill to me on many levels.