The other advantage to Tamar's observation about separate prg out of one big prg or class, is maintenance. In a huge app that calls a function that could be anywhere or has code in a class you can't view while there's an object based on it, code inside other prgs or deeply embedded objects is a recipe for author indispensability because it can take anybody else hours to pick through with Gofish or traversing documentation trying to track down the culprit code. Whereas if it's in its own prg, it's directly accessible in project manager. FWIW I spent about a month out of the last 12 ripping stuff out of methods and massive "Set Procedure" prgs into linear files for this exact reason: now you can maintain/edit something in seconds that used to involve as much as 10 minutes just trying to track down/trace what's going on.