>>>>>>>Thank you. So far, the advantage (IMHO) in using the PRG without declaring the FUNCTION is that I don't have to SET PROCEDURE... Calling PRG should always work since it is in the .EXE. Since no one brought up any disadvantage(s) of using PRG without FUNCTION, I will go that route.
>>>>>>
>>>>>>There's another advantage: if you keep all of them in the same folder, you can't have duplicates, which is easy to do with set procedures. If a duplicate is detected it's actually not detected, the last one in a prg is the one (if in same prg), or the first declared one takes the day (or the last? haven't had that in years). So if you create such duplicate functions, you have just won the ticket to a whole afternoon debugging session.
>>>>>>
>>>>>>There are limitations, though - while any other filename can contain spaces etc, a prg-as-function has to have a name which conforms with the stricter rules for function names. Also, it has to be on the path, as you can't have a path in a function call. Both attempts here led to errors:
>>>>>>
>>>>>>? prgs\dcmake3()
>>>>>>? "prgs\dcmake3"()
>>>>>
>>>>>On your point of spaces in the file name, I would never even think of creating a PRG with the space in the name. The only documents/files that I ever create with spaces in the name are Word documents. Pretty much 100% of other files I have created, I use the underscore ("_") if I need to separate words. So this limitation is not significant for me.
>>>>>
>>>>>I don't quite understand your point about "can't have a path is a function call". Why would I use the folder name in the function call? The function is in the .EXE so I would only call it as
>>>>>? dcmake3()
>>>>>
>>>>>Thank you for your input.
>>>>
>>>>One big advantage is the exe is not filled with functions/procedures that are not required by the system.
>>>
>>>True.
>>
>>Here's another one: You have a massive .prg with a ton of functions. You want to enhance one of these. You make your code change. In order to run it you must compile it - which is slow because it's a huge pig - then set procedure to it - which used to be slow, but is certainly slower than just executing it because it's another command to execute, then execute the function. That inefficiency alone is worth stopping this outdated backward way of "organizing" code.
>
>I agree with your point, in principle. But the speed of execution or compiling is not something that would make me change my design/approach. Todays' computers are so fast that making something run 1 second faster or even 5 seconds faster is not a big deal for me.
You're not understanding the point. It's not the speed of execution I'm talking about - it's the negative impact on developer productivity of having to do all those extra steps. For that matter a slow routine often indicates the wrong thought process was applied. I often get major speed improvements in other people's code. Most drastic I can remember was I worked (unfortunately for) a guy who spent an entire week trying to do a simple task - I did the task easier and faster in only a few minutes - and he freaked out, calling me a show off and all kinds of aggressive unprofessional behavior. He thought he was such a genius too.
http://fox.wikis.com/wc.dll?Wiki~VFPSetProcedure~Wiki
