Hi Mike,

>There should indeed be discussion. There is a problem that needs to be solved. The problem is a lack of planning in the organization of software modules at design time. Can you tell me where I would put a function called Weekdays? I believe it should be it's own .PRG. Your first attempt SHOULD be to MODIFY COMMAND WEEKDAYS. So with no thought you can find my .PRG. You need only to guess the name of the function - which should be obvious. Just as with a language, the word ball represents a physical ball. The name of the function must represent the function. You should not also have to guess where it is stored.

I'd would store such function into a procedure file, where all functions of a project are listed. Personally I don't like to have numerous PRGs floating arround and cluttering the project manager. As for searching, the document section would list those efficiently. Only functions that are tightly coupled and have a very specific function might deserve a location into a seperate PRG (e.g mapi mail functions). PRG classes use thoughout the project reside in another PRG.

>What is the best form of organization? There is a spectrum of everything in one classlib to one class per classlib. In a single developer shop, it would probably be OK to put everything in one classlib. In a multi-developer shop it would quickly become really awkward.

Not neccearily. We are doing that for a project we are working on all the time. We are working with 4 developers on one project. Since we are scattered accross the globe everyone has his own version of the code doing their work in their area. Once someone completed the task he sends over the modifications and I'm getting all thing together. Optimal? No, but certainly workable. It does not create much difficulties in getting all modifications in nor much time is lost with it. After a build has been completed and tested, the new source code is distributed again. Our developper have expressed their desire to have a local version of the code, Using sourcesafe or TS/Citrix is not a viable option for multi developper purposes as far as I'm concerned. Issues like distribution, language, installation, DLL dependencies are much quicker caught when everyone has their own development environment. Besides this, it does not create a single point of faillure when the internet connection goes down. I'm aware this strategy is often not an option, but it works reasonbly well for us.

>Which approach works in both a single developer and a multi-developer environment? The answer should be obvious.

Maybe to you, but not to me. Both can work.

>I already know I cannot find your classes - without reading through documentation - if there is any, or asking you. If you leave the company before I start there, I'm screwed.

An overvalued argument if you ask me. With only a few classlibs you only have to search within a few classlibs, I have a problem with having hundreds of PRGs and VCX classlibs. I don't see how this makes it easier to find a class. It probably takes a few days to get a feeling where is what and how the program is constructed. And this applies to any big project whether you use one or the other organisation. And of course, if you really cannot find it there is always the 'code references' tool that will tell you where it is located.

>I may chose to just build another one. If I need to fix yours I will have to find it, check it out of source control, make the change, recompile not just that one function, but the entire library, test it and then hope it checks back in to source control.

If you change only one class, it will only recompile that class, not the entire library (unless of course you specify RECOMPILE)

>Conflicts with other developers changing that library can require me to manually intervene in the integration process. There are workarounds, like text searchers and merging, but they are just workarounds.

Again this depends on how you organise things. We don't use VSS. It just is not worth it to us and is really a tool that is not suitable for VFP like development where resources are tables. Each developper has its own responsibility and only one developer has the responsibility of building a new version and getting all changes together.

>We don't build database multi-user applications that way! The user does not get the entire DBF file sent to them, change it, and then we examine the entire file to reintegrate those differences. In a properly normalized table such conflicts rarely happen. The record is the lowest common denominator in a table. The file is the lowest common denominator in a file system.

Not sure what you're getting at. My opinion is that a VFP project should be only a very few files containing all the sourcecode. Copying a project should only be such as copying a file. Well, I'm aware this is an illusion with VFP, but going for independed files really is going backwards IMO.

>Assuming everything is left broken down, I can categorize and cross-reference the functions in many different ways. You could categorize them your way and I could categorize them my way (if we think differently) and neither of us would be hindered by the physical arrangement.

Not sure what you're getting at here too. The Documents pane will categorize functions in a PRG, the project manager will have classes categorized in a classlib.

To me, as we have been throught this before, it is just a matter of personal preference. Things could certainly better accesible with certain functionality within the Project Manager (I know a few people have been busy creating a new PM), but to me it is not something I worry about at the end of the day.

Walter,