Walter,

>>I'm not talking about what is possible or what you do, but what is optimal.
>
>What I'm trying to say here is, what you define as optimal might not be optimal to another so quickly falling into the personal preference category.

No. All issues can be solved logically as long as the other person has an open mind. I'm suggesting a new way to organize the files. That requires creativivty and thought and a willingness to abandon habitual thoughtless approaches. Knowing that you are unlikely to agree with me why do you bother involving yourself in my discussions with others? I was not addressing anything to you, yet you deliberately interrupt with nothing positive to add.

>
>
>>>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.
>
>I don't agree. the document section is a helpfull tool in determining what is in an opened file (whether it is a PRG, class or form). I don't see it as a workarround.

The document section would not be required if the PROBLEM was not so widespread. A solution to a problem that should not exist in the first place is just 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
>
>I'm well aware what tightly coupled means. It often is used in the wrong context and is a matter of abstraction. Functions that have a very specific goal within a module can be tightly coupled with other functions within the same module. Those functions generally are not called outside of the module, still making the module itself losse coupled. Tight coupling of less related functions generally is bad and this is what everyone is pointing to.

How do you speak for everyone? You don't see coupling as I do. You have no qualms about having a duplicate code in the same method of different classes. That tightly couples the individual methods to each class. I believe you have confused design-time with runtime. A single copy of the code at design time is a blueprint. Everything at design time may be seen as a blueprint of the instances of the same things at runtime. Multiple instances of several classes can share the method's code or even access a separate object with that method's code at runtime.

Loose coupling of everything is the ideal. Everything is built of component parts. If one imagines the blueprint for an atom it would have one set of methods and properties. At runtime there are many instances of the atoms with different properties. I cannot imagine how any code in an atom's methods would be copied to any other object.

Things are built with lego blocks or bricks or wood or screws etc. None of these things are tightly coupled before assembly. They are all designed as independent things - loosely coupled, clearly named. Everything is composed of components down to atoms and farther, except huge tracts of code.

[SNIP]

>>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.
>
>That won't happen for a number of reasons:
>1. You cannot just drop a class over another. You first have to delete the original.
>2. Your original one still exists in the classlib if you delete one. It is only marked for deletion.
>3. We always make sure we have a copy. Even if we don't have an inmediate backup, we can recover from the EXE file itself.
>

You misunderstood. I obviously would have to send the entire classlib. You can replace your classlib and thereby any changes you might have made in your classlib are at risk.

>>>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?
>
>You really want to have a flat organisation of PRGs and classes in the project manager. Flat means I have to search sequentially. I have at least two levels of organisation: 1. The Classlib name or procedure file name, and within there the specific class of procedure. Having two levels by definition makes it easier to find a specific class or procedure. You cannot refute this.

I most certainly can refute it. When I have to assemble anything, if I have to constantly open different drawers to search for the parts instead of having them laid out in front of me, it will take longer, even if I know what parts are in which drawer. With the current environment all I can do is leave all the drawers (classlibs) opened (expanded). So I'm back to searching through them all. What benefit was gained by keeping them all in the different classlibs?

>
>Your counter argument is that it might be too difficult for you to determine in which classlib or procedure file it is. In the case of a class in a classlib, in the worst cases, you'll have to do what you have to do: sequentually search in the PM for the class.
>
>And I can see where you comming from, by having a personal preference to do a MODI COMM in the command window. Well I don't work that way. Most of the time I don't know the exact name for the class I'm looking for (And I misttype a lot). I pick it from the PM or if I have to digg through a class hierarchy, I use the possibility to drill down to the class code.

I often use the project manager and not modi comm. I use MaxFrame and I often cannot even remember what classlib contains a particular class. I often remember the class name. I see it like knowing I have a Wallet, but not knowing what pants I left it in.

>
>So you are comfortable with the way you do it, I'm confortable with the way I'm doing. Doing it optimal here is just a personal preference.
>
>>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.
>
>I think you have to dive into you OO books again. OO is about abstraction. BTW, I don't see where this argument fits in the discussion.

I don't have to look into OO books. A ball is an abstraction of an instance of a ball. I believe in naming the source stuff (classes/functions/methods) clearly (like ball) so I can reference them and reuse them.

Wallet is the actual object. Brown-Pants-Pocket.Wallet is not the name of the object. I simply want to reach out and grab my wallet. I can do that in software without having to complicate the matter by deliberately or accidentally hiding a single class in some classlib.

>>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.
>
>Like you can in the document pane. Anyways, If I'm looking for a class that has to do with my crystal report handling I don't want to wade through all other hundreds of classes in my project. Just clicking the Crystal classlib and drill down to the class I need (and yes those are sorted alphabetically).

Let's assume you already know the name of the class you were looking for - ctrCrystal. My way, it's ctrCrystal. Your way it may be in the Crystal classlib or in the reports classlib or in the ole classlib. While you're looking in those, I'll already be using ctrCrystal.

>
>In your analogy. If I'm in the room and the room is filled with stuff on the floor sorted alphabetically, I'm going to be mad. If I'm looking for a book, I'll look on the bookshelf in the room. If I look for clothes, I'll look into my wardrobe. If I look for my CD, I'll look into my CD collection. You are asking me to throw all differing things on one heap sorting it alphabetically.
>

Perhaps the room analogy wasn't the best. If you want to build a wall in your house, you get wooden studs, drywall panels, screws, nails, a hammer, a drill etc. If you have to go open different drawers for each thing as you need them, you will go very slowly.

>
>>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.
>
>See above. It is just how you organize things, and as I mentioned, the document pane can sort alphabetically as well as the classes in a classlib, so I don't see how your argument makes sense here.
>
>>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.
>
>Giving meaningfull names is a neccesity in both circumstances.
>
>>>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.
>
>Sure, but who would do that ?? Only the changed code should be replaced, not the entire PRG.

The entire PRG is recompiled when only one change is made to one function in the PRG. If I send you the PRG again there is a risk that my changes will overwrite yours. So again, you have to either let some program determine if there are any conflicts and merge the differences or in my case, no two people would be working on the same source at the same time in the first place. I'd only need source control to keep the different versions of each piece, not to have it attempt to merge the code from different developers.

>
>>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.
>
>If this is a strategy to make a terrible source control product like VSS work, then you might classify your proposal as a way to make VSS work. It certainly is not the way I like to work. I don't see your proposal as a way to make my work easier in any way.
>

Not unexpected.

>>>>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.
>
>I would like to see it the other way arround. I'd like to see each and every resource stored in a single database table, so that we are able to run an entire application from one table, where mainenance and source control is a breeze:
>
>1. Checking in and out is setting a flag on the (main) record of the resource.
>2. You can do your maintenance in production since you don't have a real executable, but just a table. Users will get your new version as soon as you release the flags.
>3. Source control is going along with the scheduled SQL server backup.
>4. Reverting to a prior version is going trhough the transaction log.
>
>A dream? No this is already accomplished by ERP/ERM vendors. It is just a shame the MS does not 'get it'. VSS is ten steps backwark if you ask me.
>
>>There are technical merits to this idea, despite your opinion.
>
>The technical merits come from the outdated VSS principles if you ask me. Also the technical merit have disadvantages due to VFP/VSS limitations. I know what is optimal (see above), the only problem is how to achieve it...
>

Truth is, I originally didn't ask you. However, that design only supports my idea. Each record in that system would be a component in the system.

>>> 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.
>
>An opinion does not need evidence, it is just an opinion, just as is yours. You don't come with evidence either. You decide what is easier for us while not having any evidence for it. Hence we are talkign about personal preference.
>

Indeed I do have evidence. I used to keep things in several classlibs until I got tired of trying to remember where I put things, when I already knew the name of the thing I wanted. I want my wallet I don't want to go searching through all my pants first. By naming my classlibs the same as my class, because it seems obvious to me that an SCX holds a single screen and the screen's components, so should a VCX hold a single class and it's components. Now I can simply access the ctrWallet class in the ctrWallet classlib directly, quickly, easily. You have never tried what I'm talking about, but you seem to know it can't work. On the off chance that perhaps you're right, I listen to you, only to find I'm wasting my time.

>>Copying a project is such a rarely done thing, why be concerned with having to copy one file?
>
>When I backup a project I copy it onto a memory stick to take it with me. Now I first have to zip it. It is a matter of abstraction. If I look at my hardisk I don't want to see all files that might be needed for this or that. I'd rather see the big abstracted picture, not the individual cryptic files. Wouldnt't it be nice if you looked at your hardisk and only saw the software packages installed on your computer and the documents it generates, rather than all individual files which have created a nightmare of our harddisk ??
>
>Again it is a matter of abstraction. Not about the individual details...

Now I have no idea what that has to do with the discussion.