On 08/21/2012 10:30 AM, Jonas Maebe wrote: > > On 20 Aug 2012, at 18:15, Timothy Madden wrote: > >> This story is inspired from a real case when *lots* of user code >> suddenly stopped compiling after JDK 1.2 was released, with a new List >> class, which users had to import from a different package until JDK 1.1. >> In this case is wasn't even a third-party library that triggered >> conflicts in existing code, it was the system run-time library. Since >> that story most Java programmers prefer to import and enumerate each and >> every class they use explicitly, instead of importing the package that >> provides the classes > > Importing a single class in Java still requires you to specify the full > package name, so how would that help preventing compilation failures in case > a class is moved from one package to another?
My problem is about a new symbol in a new version of unit X, overriding an already-used symbol from unit Y, as soon as I upgrade to the new X and re-compile. If a symbol is removed from unit X, as you say, that is obviously a problem (if not a mistake) with unit X (supposing the symbol was not deprecated already). If a symbol is added to unit X, on the other hand, that is a legitimate (and expected) case, and here you might turn to the language itself for some help to ensure your future. By the way, as it turns out C++ has a similar problem with its "using namespace std;" directive, but it stands a little better in that the directive is explicitly required before it can have any effect, and user can also rename the namespace instead, to some meaningfull prefix, to make it easier to prefix all symbols when used throughout the code, if they so wish. Thank you, Timothy Madden _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal