>>Hi,
>>
>>Say I have a function that I want to put into a separate PRG file. I can do it without declaring the FUNCTION FunctName within the PRG file. And then call this PRG name as a function. E.g.
>>

>>do MyPrgName with tParam1, tParam2
>>

>>
>>If I add a FUNCTION FuncName then I would have to do SET PROCEDURE to MyPrgMane ADDITIVE (somewhere at the top of the app) and then call it as
>>

>>FuncName( tParam1, tParam2)
>>

>>
>>What are the advantages or disadvantages of having the function inside a PRG without the FUNCTION declaration?
>
>Just seeing this now. It's worth noting that through VFP 6, there was a huge speed penalty (an order of magnitude) for having that Function declaration in a PRG. That, in and of itself, is an indication to me that the original developers intended PRGs to be stand-alone programs without headers.
>
>As for the argument elsewhere in the thread about standalone PRGs vs. methods, it seems pretty simple to me. If what you're writing can be seen as basically an extension to the language (a function the VFP developers would have included if only they'd understood how much you'd need it <g>), use a PRG. If the routine depends on the presence of certain data items (other than data stored in a table), put it into a class with the data it needs. What base class that class is based on or where it falls in the inheritance hierarchy will vary.
>
>Tamar

Thank you.