General information
Category:
Coding, syntax & commands
Environment versions
OS:
Windows Server 2012 R2
Network:
Windows Server 2012 R2
Virtual environment:
VMWare
>>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.
It comes down to standards and practices. Using a common methodology in a system means you learn how it works, and then rely on that design. The design Christian outlines is quite common in VFP code that derived from FPW, FPD, or FoxBASE+. I have seen it at several companies.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only