Mike,

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

The goal of my participation in this thread is to provide some counter weight to your 'opinion'. It is up to the lurker what to do with it. I truly don't like one side views.

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

So how are you going to solve the problem of jumping from one method to another in a class or form ?? This is where your proposal does not have any answer for: You cannot have each method of each object in a seperate file. The document section will give you the info of what is in a PRG, Class or Form. Could it be better ? Certainly ! Is it usefull ? Absolutely yes.

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

Tight coupling within a module often is refered to as cohesion. Find the literature and see the relation between cohesion and coupling. You'll see that they both are the same, except for that that cohesion is tight coupling within a module and tight coupling is cohesion between different modules. Hence my statement that tight coupling within a module (cohesion) is not neccesarely bad. I don't speak for myself here. It is in the literature.

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

You're drifting. Where did I say this in this thread? But you're right. I'd like to have classes as encapsulated as possible, meaning the class should have as less dependencies as possible. If I want to distribute the class (or post on a forum), I'd like everyone to be able to just copy the class and work with it without having to worry about all dependencies.

This is directly related to tight coupling. If in a class you refer to a lot of PRGs outside of the module (class) this generally is a bad thing. Better is to all functionality integrated into the class. Take for example ActiveX controls like the ones use for crystal reports. Distributing the CR runtime generally is a nightmare (unless you can use merge files) because of all the dependencies (tight coupling). It would have been way better if all functionality was integrated into one or very few files.

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

Coupling has all to do with design (time). Runtime is irrelevant. Hence I don't see the relevance of your statement above. PRGs are not copied into the class or module: they stay outside wheter on runtime or designtime, meaning tight coupling.

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

Atoms are encapsolated and independed. If you move the atom, you move all functionality. If you place your atom into another project, you only have to take care of the atom and don't have to worry about dependencies you have to drag with it. Atoms do not share neutrons with other different typed atoms. Developer should not care about the internals of the atom, how it is implemented, but just have to know their 'interface', and should not have to deal with external dependencies. If your atom depends on a function outside, it is a direct prove of tight coupling of independed modules, thus meaning bad.

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

You're drifting. Tight coupling is about functional dependencies. Something that hardly applies to physical things, but rather to procedures and workflow. I'll try to give an example why functionality should encapsulated.

1. I'm building a class that communicates with other systems though TCP/IP ports and encrypts/decrypts data. I use the Windows encryption API (reuse). Now it seems that different windows versions use different encrytion algorithms. Now I'm screwed. If I had build in the encryption mechanism into the class I would not have that 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.

That would be stupid and something you would never to, just open both classlibs into two projects and drag and drop classes.

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

First of all, assembling things for a new project is something you do very rarely (I don't start new projects each day, nor week, nor month) so optimizing this goal is something very foolish IMO. Second, When assemblying things I'd probably think in layers:

1. I Need my dutch crystal reports class
2. I need my dutch base classes
3. I need my dutch common procedures library.
4. I need my dutch startup file template.

Then I just copy all the libraries into a new project (just a few seconds of work). Think about doing this class by class, prg by prg ?? Then If I need some specific classes I need to work with I've done before.

5. I create an application specific library and drag and drop copy it from everywhere.

I don't see a problem with the above, as I don't see what I gain with your method. And besides Since I do this work so infrequently I really don't care all all if it takes me 5 minutes or an hour to do.

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

Maybe your problem is in MaxFrame. I use my own framework and often have the opposite problem. I do not know the exact classname, but I know which library (because of the type of class) it is in. Esspecially the application specific classes are prefixed for a certain type. E.g.:

dlg_ Dialog form
dat_ Application Data entry container
set_ Settings Data entry container
cnt_ Composite control container

So even within my application specific classlib I have an extra way of searching. But with a lot of classes, it also takes some time to find the right one.

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

Sure I do believe in naming classes and methods clearly too, but how does this fit into the discussion ? So where is the abstraction and inheritance up here? See the following:

Life - Animal - Mamal - Bear likes - Grizzly bear

Only the Gryzly bear is something physical. The parent classes are all abstracts.

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

You've totally lost me here. What does the physical storage of a class have to do with the logical handling of it ?? Whether the class is stored in its own VCX or PRG or classlib does not matter att all from a technical point of view. It seems you're having a problem in relating the physical and logical things. I'd rather see all things well organised in the PM in an efficient way (preferably in different ways subjected to personal preference). How they are stored physically is in this respect irrelevant (It is relevant when having to deal with technical limitations when it comes to source control however, but that surely is a different matter).

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

LOL !!, If I'm looking for my crystal reports class, I don't have to think in which library it is. It is in the crystal library. If you have a problem remembering this kind of stuff, you probably are better of searching for another job. Anyways, I open up the Crystal library and since there are only about 10 classes in this library, I inmediately click the right class. Probably takes me 2 seconds. As oposed to your method, I have type C and search the whole list of classes to find it, which will take me about 20 seconds or so.

So no, I don't agree. I know where to find things in my projects. If I'm working on otherones projects, It probably take a while before I know where is what, but that does not mean that your way is quicker. I'll be irritated to death by the fact for each and every class I've got to wade through all classes or prgs to find what I want. Esspecially if I don't recall the exact name for it.

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

I think your analogy perfectly pionted out where the sore spot is. People don't sort their lives alphabetically. They place everything into a hierarchy of abstractions.

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

Hmmm, lets see. This analogy does not fit. It should be about how to find a single class, not about how assemble one out of different objects.

If I want to build a wall:

1. I go to the woodstore and buy wooden studs (open woodstore library and pick cnt_woodenstuds)
2. I go to the do-it-yourself_shop and buy drywall panels, screws and nails (open up do_it_yourself library and pick the class)
3. At home, I open my toolbox and pick the hammer and dril (open toolbox library and pick the cnt_hammer and cnt_dril classes).

So lets say, you are constructing this wall, and have 4 different types of screws and 4 different type of nails. Are you going to lay everything on the floor alphabetically or are you going to group different type of nails and screw together ??

<snip>

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

Again, only the functions are changed, not the PRG. BTW, it is never a good idea to have two developers independently working on the same source. This is calling for problems in any way you organise it.

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

Based on physical files rather than on logical units. Have you ever seen an ERP/ERM solution using repositories and how they organise source control ?? I guess not.

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

This is not evidence, but personal experience. As I stated before I have the opposite problem: I do know in which classlib to find a particular class, but do not know the exact name, and that does not mean it does not have a logical name. I have a total different approach to define classes and libraries and am confortable with it. This is my experience.

You want to create evidence out of personal experience. I'm glad for you that your method works for you, but I find it strange you think you can project this on each and every developper out there. And as for trying you methodology. If I had to try everything that everyone has proposed as the ultimate solution, I'll be programming in the .NET and facing the data integration problems which I already knew at forehand. No thanks. This is the reason why people can reason and have intuition. My reasoning says that a gain nothing and lose much.

Walter,