On Tue, Aug 21, 2012 at 1:43 PM, Timothy Madden <terminato...@gmail.com> 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.
Yes. > 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. Yes. > 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. Obligatorily, not. You can use a pratice to use unit.func always or, as I do, use a prefix in all identifiers: unit: foo_unitname proc/func: fooProc, fooFunc -- maybe use class procedure/function instead. classes: TfooClass global var: DO NOT USE! global consts: FOO_CONST_NAME -- maybe use class const instead. > 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. Yes, Yes, even people saying otherwise. Marcos Douglas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
