Walter

I'm not talking about what is possible or what you do, but what is optimal.

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

The document section is a workaround.

All functions are supposed to be loosely coupled. The example you gave is not tightly coupled. http://www.cs.unc.edu/~stotts/COMP145/coupling.html

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

So let's say I send you a new modification to a class in a classlib that you just worked on. By mistake you drop mine over yours and lose yours. That risk is what I'm trying to avoid. That you chose to live with that risk is your problem.

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

You have a problem with it, but you cannot refute my idea except on the basis of personal preference. What exactly is the problem? That you get to see too much stuff? The fact is all the stuff is in the project anyway. How exactly is an arbitrary grouping better? Does the project manager open faster because there are few files? When you expand the classlibs it will still show all the classes. Maybe there will be more clicks to expand classlibs? What are your technical reasons?

Every physical thing has a name. Every piece of code and class should be treated like a physical thing. That is IMO the essence of object oriented programming.

If I fill a room with toys without sorting them that is clutter. If there is only one ball, you can find it with lots of digging. If the things are sorted alphabetically and arranged on the walls you can find it faster.

If I put things in different boxes, a list of what's in what box would help you find the ball but only as you go through each box's list. If I throw the toys unsorted in each box, you still have to dig. That is hardly better organized.

Give things clear meaningful names and put them in an alphabetic list like the project manager and it is easy to find. Have an ability to produce various lists and you can always find things.

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

I said function, as in a large PRG full of them. Regardless of multi-function prgs or multi-class classlibs there is the risk of my changes overwriting another developer's changes. Unacceptable.

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

What I'm talking about makes using VSS easier. Otherwise there is too much room for human error making for multiple points of failure. You are manually managing the problems. Good luck.

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

a function/procedure and a class are the lowest form of modules. I propose a VCX is supposed to be used like an SCX. It is a holder for a class and the components of that class. It should not be used as a collection of various classes nor should the prg hold a collection of various functions.

There are technical merits to this idea, despite your opinion.

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

Just your personal opinion without any evidence to support it again. Copying a project is such a rarely done thing, why be concerned with having to copy one file? It is the exe that is distributed, not the source. The source is like the parts of the car in the factory, not like the car on the street. The parts in the factory are readily available to the assemblers. They are not hidden in different rooms in the factory. The new worker has everything they need to assemble their part. They don't spend a couple days getting familiar with what rooms have their parts.

[SNIP]