On 21/08/2012 17:43, Timothy Madden wrote: > On 08/21/2012 03:10 PM, Jorge Aldo G. de F. Junior wrote: >> "With no error messages, or even with no changes to the program since 1 >> and a half year in the repository, the scientific calculations are now >> all blown up, and program outputs only errors at runtime. The maintainer >> now curses and chases me for having the nerve to leave a program >> known as working in such a horrible mess in the repository." >> >> Never tested, but doesnt the compiler warn of the colision ? if not, it >> should. > > The problem is the language exposes my program to the risk of future > collisions from the units I use. > > A warning is a little beyond the scope of this problem, because my > program is working perfectly as of now. > > But next year, some unit I use will have reached a new version, and if I > merely recompile my program I have already have a conflict, that was not > there last year. > Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*;
This AFAIR is sane programming practice, EVERY change you make, you test. And your managers HAVE to allow room and time for that, no less, no more. If they don't, they shall not be IT managers. There is no room for 'program done, out the door' culture any more. /IF/ there is one, just treat the program with updated/upgraded units as completely new product, completely detached from its original, and show it as such to the managers, if they need explanations. (even in free-software/open-source, 'releases' always/usually carry the versions of libraries/sources they've been tested with, not just in Pascal, take a look at what your average C (including ++ and #), Java and other programmers do as 'dependencies'. Otherwise no one ever could wrap their head around the resulting heap of s*t.) > And the new version for the unit in question is fully compatible with > the old one, so you would say my code should still compile. > > The question here is if it would be possible for the language to prevent > this problem, like python (and others) do. > > Otherwise, I could never upgrade a library, even if the vendor announces > full compatibility with the previous version. Because I will still > expose my old code to the risk of new collisions. > > Even worse, as the language currently stands, it is possible to upgrade > a unit to a compatible version and get a different behaviour from my > program. Without a single warning from the compiler. > That's what /testing/ is for. There must be a rule: no untested changes are published. If there is none in your company, then *you* make one for yourself and keep to it. > Thank you, > Timothy Madden > HTH, Lukasz _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
