>>>There is only one strong reason for doing this (bundling multiple functions into one PRG), and it would be to implement abstraction / polymorphism.
>>>
>>>You would create the same function in two different PRGs:
>>>EmployeeProgs.PRG -> FUNCTION Save
>>>CompanyProgs.PRG -> FUNCTION Save
>>>
>>>If you are in the Employee.SCX, you set procedure to EmployeeProgs.PRG
>>>If you are in the Company.SCX, logically set procedure to CompanyProgs.PRG
>>>
>>>Both screens can be generically calling SAVE(), while obviously the actual actions are different from each other.
>>>
>>>So if someone were to create a procedural code, that would be the way to go. Of course it does not make sense because with OOP you have much better ways to accomplish this, but in theory that is the one case where you cannot work with separate PRG's.
>>
>>Boy, would that make debugging hard. In an OOP world, where those are methods and thus context is clear, sure. But for procedural code, I'd consider that bad practice.
>>
>>Tamar
>
>Yes I agree, but it has been done in some projects I have seen.
>
>If you were to run your tool to split those functions into PRG's it would not work. That's why I said in this scenario you don't have another option than to stick to procedure files. I don't know of any other case where procedure files are absolut mandatory.

I see. I thought you were recommending it. Instead, you're saying that sometimes you're stuck with it. Fair enough.

Tamar