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

The methods in a class should only be those that belong in that class and not those that can be made modular unto themselves.

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

Everyone interprets the literature. That doesn't make your interpretation right.

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

Distribution of the source files is irrelevant. It is the distribution of the exe that all we do is for.

The literature also says there shall not be any copies of any code. Everyone seems to believe that. Encapsulation applies to the objects at runtime, but is planned for at design time. It does not refer to the location of the method code. A UDF is encapsulated. Dependencies between a class's method and a UDF at design time is not relevant. It is only important that there be few 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.
>

The key is to have RELEVANT functionality in the class. Will you also add methods that perform the same things as the commands in VFP? If not, then there should be no problem with calling UDFs.

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

See? You've completely inverted the phrase tight coupling. Tight coupling would be to put all code into a class or module. Each thing is supposed to have relevant code in itself. So a weekday UDF is encapsulated. When an object at runtime needs that UDF it can call it because there is a single small connection between them. The two things are loosely coupled at design time, but they are intended to interact at runtime without being interwoven at design time.


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

Atoms do not share neutrons at runtime. The neutrons inherit their methods from the class neutron. All atoms therefore depend on the neutron class even at runtime.

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

OK, so dismiss the printer driver and put all the control codes back into your application so you can call it "encapsulated". The application is encapsulated. The printer driver is encapsulated. The printer is encapsulated. The application needs the printer driver to communicate with the printer. The application is loosely coupled to the printer by the printer driver.


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

Manually dealing with the problem.

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

and I'm annoyed to death to have to search different buckets (classlibs) for different types of classes (types of nails or screws). If I handed you a bucket with different types of nails or screws, you might indeed pour everything on the floor to find the one you're looking for.

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

True in the physical world. Mentally I may indeed be sorting everything alphabetically. I must be using some kind of search to mentally know I have a thing called a wallet.

People don't physically throw different types (classes) of things together in the same bucket (classlib). The physical world is not the same as programming at design time. Programming is more like working with the blueprints before building things.

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

You go to home depot and have to ask where is the wax toilet bowl seal or you have to begin a sequential search aisle by aisle through the plumbing section. You already know what you're looking for. An alphabetic index and a map is often provided, but not at home depot.

The analogy does fit. We are constantly building walls. Every thing we build (class, screen) is an exercise in building walls. We have to decide how to design every thing so they facilitate building walls later.

I will keep each type of nail separate from the others. Each type is a class. Each nail is an instance. I will use a particular type or class of nail. I don't have to worry about how the designers of the nail got the code for the hammer method at design time because when I have the nail in my hand it's runtime. It has already moved from design through instantiation to become a physical object. In code the object only exists at runtime. If the nail hammer method calls a UDF to determine when it will bend, I don't care when I'm using the nail.

If I can call that same UDF, I'm ahead of the game. At runtime I can call that same method without interfering with the nail. That's because at runtime the nail is fully encapsulated, regardless of the fact that it depends on the UDF as part of its design.

Having a box of one type of nail is having a set of instances, and it is the same as having a single class. Putting different types of classes into a single classlib is like putting different types of nails and for that matter other types of things into one bucket. This problem is compounded in the physical world by having many instantances of each class in the same bucket.

>
><snip>
>
<snip>

If you have all functions in a single PRG, when a function is changed and saved, the operating system shows that the PRG has changed. You cannot escape two developers working on the same source file if they both need to complete a task now.

I'm not trying to force all developers to do anything. I suggested to one developer to keep things as granular as possible. You decided to butt in. You could have written to the original poster instead of arguing with me but chose not to.