>>>>There is ABSOLUTELY NOTHING to gain performance wise to split function up into procedures.
>>>
>>>First, as I just said in another comment, through VFP 6, including a Procedure or Function header in a PRG file that contained only a single routine, had a performance penalty of about an order of magnitude. Ted or I (don't remember which) tested it when writing HackFox.
>>
>>I don't think we should take VFP6 as performance benchmark. So much has changed since then.
>>
>>>Second, to do a realistic test of what the penalty is today for a procedure file, you'd need to try procedure files of different sizes. I strongly suspect that performance drops as the number of routines increases.
>>
>>Done that with a large procedure file. No difference. It is just as fast.
>>
>>>Finally, even if there's no performance penalty, procedure files have other negatives, including making it hard to find stuff at design-time (which includes that they can make Thor's Find Definition fail). For me, the worst is that under some circumstances, changes in a procedure file don't show up when you're testing in the IDE. I've been bitten by that a lot.
>>
>>That really depends on how you organize things. If you have a large projects with hundreds of functions it does not make any sense to load them in the project manager. It makes sense to put them into a single prg library if they are used within the context of the library purpose. It makes it a lot easier to redistribute and hides away functions that are never used outside of that context. Nowadays I'd load everything into classes, but if I'd have a library that has to do with FTP, containing dozens of functions that are used from one main function within that same procedure file, I just don't want to see that stuff in the project manager.
>>
>>It conflicts Mikes own argument of cohesion he likes to brag about.
>>
>>>In my view, procedure files stopped having a purpose when the Project Manager was added in FP2. When it's my call, I will always get rid of them. (I wrote a tool to do it, which is now in Thor.)
>>
>>I've got two procedure files left with functions for a variety of reasons, but since my project manager aready spans 150 prgs and classlibs, there is no benefit to clutter it up with more stuff.
>>
>>Anyways, this argument was about performance. It has no benefit to put it into seperate PRGS.
>
>You don't know the first thing about cohesion

Lets see. I hold a degree on software engineering. I very well know what cohesion means.

>If I have a speed.prg which is a wrapper to set up the speed.dll, how is it being in any procedure library affecting cohesion, which only matters at run time and now where the files are stored at design time.

Did you say "Procedure library" ? Isn't it just the point that if I got a library for doing FTP, Webstuff, encryption, data access, etc, The functions are grouped together in one (SET PROCEDURE) library?

Cohesion means the degree that things that belong together are logically or physically grouped together. If you have 20 functions dealing with FTP, but most of them are only used from a few key functions. WHAT IS THE F*CKING SENSE to put them all in the program manager as separate PRG files. Its not easier to distribute to another project, its not easier to develop new functionality and not easier to debug or refactor either.

Can you imagine someone saying: The FTP function does not work anymore, what are the most recent changes? You'll have to go through your source controls for 20 files in stead of one.

>I don't even waste my breath on you.

You already did. You're not being very consistent mike.