Hi mike,
>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.
>>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.
>All functions are supposed to be loosely coupled. The example you gave is not tightly coupled.
http://www.cs.unc.edu/~stotts/COMP145/coupling.htmlI'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.
>>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.
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.
>>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.
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.
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.
>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).
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.
>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.
>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.
>>>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...
>> 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.
>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...
Walter,
