Hi Mike,

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

You did not answer the question. How do you browse or walk through methods in a class or form without using the document section? The document section provides you a way to effictively haunt for a specific method or event in your class or form. Therefore alone the existance of the document section is justified.

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

Well look at the definition of cohesion. There is not much room for interpretation...

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

And you want to make sharing and distribution of classes and PRGs easier. IF that is irrelevant what are we talking about then ?

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

The literature also mentiones that there should be no redundency of data (normalisation), though there are very good reasons to store data redundent.

But sure there should be no repetition of code in the ideal world, but you cannot escape some chunks of code will be repeated in the same or similar implementation. When implementing a general applicable module (a class you might want to use outside your current project), it is often a better choice to include the funtion into the class though the function might already be included somewhere else in your project. If you are dragging this class into another project and that class is depending on some additional PRGs there is the potential danger you'll have function naming conflicts in that new project. If you encapsulate everything into the class you won't have that problem and are absolutely sure that it will call the right functions.

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

No it is not. VFP Commands are universal though VFP projects (of the same VFP version), PRG functions are not. If the PRG does not exist in the project or conflict with another function then you have a problem.

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

No I don't see.

>Tight coupling would be to put all code into a class or module.

Which often is refered to as cohesion, which is good.

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

Sure but the working of that object is still depended on the UDF, meaning tight coupling.

Now to point out the sore point, taking your weekday() function. Well what does it do ? Does it return DOW(dDate) ? Does it return .T. when a date is on a weekday? Does it accept a date parameter or does it take the current day ? Does it calculate the number of weekdays between two dates ? I don't know. Now I take your object refering to your Weekday() function to include in my project, but I already have a function called weekday() but with a (slightly) different definition. What do I do ?? What if I don't have the source code (blanked out the methods column) ?

Can you imagine writing ActiveX controls relying on code in your project (Aside from the fact that it is technically impossible). No all functionality is encapsulated into the control.

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

Some things are provides as a common library of function through the OS, printer drivers are an example of that. They provide a service to the application running on them. This is a total different situation.

Your printer driver does not depend on any function written in your application. It is an encapsulated module that only has dependencies on the OS. It is not tightly coupled with your application depending on a certain function to be available in your application.


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

Yes, as we have to deal with a lot of problems mannually. There is no automatic way which will work for us, as will apply for a lot of folks.

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

Since in my example there are 4 different types of nails and 4 different types of screws, it is not a hard job to find the one type I need. I only got a choice of 8. Drill down to the nails_and_screws library and click the one you need. You have to remember the name of the particular screw you're searching for and literally browse through hundreds of classes to find it. Good luck !!

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

It was you who likes to draw an anology between the real world and programming, not me.

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

Yeah I know. So lets take a real estate architect. He has a lot of blue prints for different buildings. Don't you think he would classify the blueprints in some manner to easily find it: Eg. Offices, government buildings, private houses etc. Do you really think he will sort it alphabettically ?

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

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

If have no idea what a wax toiler bowl seal is. If I search it, I'll search in the area where it belongs (classlib) I'll not search everything sequentually.

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

The question was, will the different types of nails be grouped together or will one group of nails be 12 meter away from another with lots of materials in between because of the alphabetical sort ? Surely not. If you put one type of nail on the table in the corner I'd expect to find the other types there as well and not on the other side of the room because of the alphabetical sorting. So if I'm looking for a particular type of nail, I open the Nail_collection_on_the_table_in_the_corner classlib and pick the nails I want.

Mixing all types of nails, screws, wood, tools, in one sequentual dimension will make it terribly difficult to find anything. This is the concept of my objection agains your proposal.

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

You totally missed the point. The developpers edit their own instance of the prg and test it locally. One person is responsible those changes make it into the production PRG.

>I'm not trying to force all developers to do anything.

You began this saying "There is a problem that needs to be fixed" in a discussion with Cetin.

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

It is a free world last time I looked. I did not notice the original message, I did notice your statement though.

Walter