Mike,

>Seems to me we're talking about only one kind of "package", not zip files. It is impossible (without copying) for the class to appear in two different classlib packages simultaneously.

A class can only be in one physical package, it can be in several logical packages.

>OK. I can see that to a point. If you mean most apps use most of the controls in cControl.vcx.

That is what I mean.

>But, when you are building the app from scratch and building your cControl.vcx, it would be more productive for multiple developers to contribute to the process if there were at least as many vcxs as developers, right?

With the way VFP interacts with VSS, yes several developers can not be working in he same classlib at the same time. If I was still in the phase where cControl.vx was being heavily developed and several people doing it, I'd let each developer work in their own copy of cControl.vcx and let the class librarian manage the integration of their work back into the one cControl.vcx that has test and production pin versions in VSS.

>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, now we're getting somewhere! I 100% agree with you here. Except you're forgetting that I would never have all 1000 lines displayed. You are right that there would be 500 closed classlibs visible, but they would have the same name as the classes. So I'd still be able to find the class quickly. There would be scrolling.

Every file requires a VSS hit, your project will take a lot longer to open.

It would also seem to impose a rather strict class/file naming structure on your environment, with the possibility of not knowing that two different classes were intimately related if their names were vastly different.

>Further, if one linked VSS to the project manager, there would be a big problem. I don't know of anyone doing that anymore though.

We do. We've found a VSS model that works quite well and supports the dev/test/uat/production releases of code.

>I feel these are not so big a harm compared to not having to refactor and increasing multi-developer productivity.

If you plan the classlib packaging beforehand very little refactoring is ever required. And IMHO the longterm programmer productivity achieved by having closely related classes in the same classlib far outweighs any future refactoring effort that might happen if the original plan wasn't so good.

>Maybe the project manager is not the best way to work with classes and code?

You volunteering to write a new one? *s*

>You can read the thread yourself.

Thanks for the ref I'll have to read it later.

>I am saying the classlib is an inefficient means of packaging - compared to my imagined utility which would let each of us organize the classes into virtual "packages". If that utility could also zip a single class and all related code into a single file so I could send it to another developer, I think that would be ideal.

Steve Black put together just such a class distribution utility quite a long time ago.