T
Thomas Mercer-Hursh
Guest
Yes. Not only is it pointlessly long, but it includes some practices which I find at least extremely strange if not more dubious. Why in the world would you have \Common\DataAccess on the propath and also have Common\DataAccess\DataSets??? (Yes, I know they did it in the OERI, but surely you know not to copy PSC code as if it were good practice. One of the rules of propaths should be equivalency, i.e., you should never be referencing two different levels along the same path. If you put the terminal directories in the code, e.g., DataSets and DataSources, presto you would eliminate 5 entries in the path. Likewise Modules\src .... is there something under that directory other that DC, GL, INV, LT, OE, and PO that you are trying to hide from Progress? If not, why not just put Modules\src on the propath and put the subdirectories in the code as packages. I don't know whether you have OO code or not, but the whole idea of a package and USING is particularly clear there. But, it isn't just an OO idea. Back in the 60s I inherited a directory structure from Varnet which had directories like gl, ar, and ap, but it was the directory containing these which was on the propath. This meant, for example, that I could have a 4 element propath that included one directory for what the developer was currently working on, one for custom source for the customer, one for the r code and one for the standard release. Within each one would have gl, ar, ap, etc. as needed so that promoting a standard release module to customer code and then modifying it, for example, was completely straightforward. I quickly became unhappy with the very large number of files under each of these application directories and so started introducing packages within the application. I.e., ar/cust would have all the programs that dealt with editing, listing, and inquiring on customers. op/orde would have everything to do with order entry, etc. This is packages, but in strictly procedural code. Sorry to rant and I know and appreciate that it isn't going to be an easy transition to fix, but if you would pick a small number of base directories (one?) and put everything under that with the package paths in the code, I am confident you would see much higher compile performance and possibly even runtime performance .... not to mention ease of maintenance. What happens now when you see a reference to X.p? You need to look in 30 different places to find it? Not to mention needing to keep unique names at the end of all of those paths whereas the path would be part of the uniqueness if you did as I suggested. How do people do these things to themselves!?
Continue reading...
Continue reading...