Hi David

>I feel that one class per classlib is nearly as much headache as all classes in one classlib.

Agreed. The fact is all the parts are in the system, whether they are contained in one classlib or many. When you buy a box of lego, you can start assembling something because you don't have to disassemble their idea of logical groups.

>
>A decent middle ground is to functionally group your classes. If you have a few classes that are related by subsystem of your app those can be bundled into the same classlib.

That works until you discover a new need for a part of that subsystem. Besides, the grouping is apparently arbitrary in most systems I've seen. They may make sense to the developer, but new people and their potential productivity are lost. They must stop and ask someone where is this and where is that? I know because I went through that scenario just recently.

More descriptive naming of classlibs would be another solution.

>You "can" do multideveloper work in a single classlib if you use a librarian. A developer does a logical checkout of a class with the librarian and functionally accomplishes this by dragging the class out of the classlib into the developer's classlib. When they are done they drag the class into something like a test.vcx and the librarian moves the class back into the real classlib. It takes some coordination but it can be done.

Yes, it can be done, but why bother? I'd rather the librarian spend time making sure the object is clearly designed, documented, robust, compatible etc. than to have him/her waste time trying to decide where to *bury* the class.


>
>>When working in a multi-developer environment with source control is it a good idea to have one concrete class per class lib. ( Think Meer Mortals where there are no SCXs all forms are in VCXs ) The Framework/Abstract classes are expected to continue to contain 1..N classes
>>
>>My gut says that there would be problems with this, but I cannot think of anything significant.
>>
>>Why it is being considered is that there should be much less conflict between developers needing to make changes to different classes in the same library. In a sense all that is being done is repeating the organizational ( or lack there of <s> ) structure of a project that uses SCX forms.