Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
Am 21.08.2012 21:42, schrieb Jorge Aldo G. de F. Junior: Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... The compiler can not detect such collisions, because it stops searching for a symbol if it found a suitable one. This also explains why you need the overload directives in certain cases of cross unit overloading (because then the compiler will search for more). This is one of the reasons why the compiler can compile code so fast: It does not need to check all loaded units of a unit (and there are units that contain many uses). So from me this gets a definit -1 in big letters. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 3:57 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: Yes, we know too... but how prevent this using third-party libs? For example, what do you think if I have a project that have a file called lnet.pas? Can I use this identifier? As much as any identifier. If you uses lnet; in the same unit where you import an unit with lnet symbol, you have to qualify it fully. I said identifier, but I mean FILE and, in that case, I can't use it. can't because the lnet project already uses, right? But I didn't know before...ohh my... and now, I can't use this project because I will got a compiler error because cant have two units with the same name. Do you think this is right? Because of this conflict that I proposed the syntax: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; That only fixed it for that compilation unit, if another unit just uses foounit that leads to an inconsistent state. First, this is an idea, so should be improved. Second, this is a problem of programmer; if he forget, sorry for him. Third, maybe this sintaxe should be used just on project (not unit) and in units only use the alias (f1 and f2 in that case). Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) I have experience with it, and it is a nice feature if it is not mandatory. So you don't _have_ to qualify. If you know that a certain unit contains a lot of fairly common symbol names you import it qualified. (like many large API units, typically you only uses an handfull symbols from e.g. Windows, and it is not mandatory for the other situations). Modula2 went a step to far to only allow unqualified use if you name the symbols. That is too laboursome. Simply unqualified (what we have now) and qualified would go a long way. ... and all its effects and sideeffects are known. I agree. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
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? (I believe there is no equivalent feature in Pascal that imports only one symbol from a unit). Indeed. Is there any form of proposal or some alternative to the USES clause, that will keep all the imported symbol names qualified by some namespace name or by some prefix I choose ? Not that I know of. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
Very tedious, but you could create a wrapper unit and/or class for each library, and expose a prefixed name instead of the original. Jeff, On Aug 21, 2012 3:31 AM, Jonas Maebe jonas.ma...@elis.ugent.be 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? (I believe there is no equivalent feature in Pascal that imports only one symbol from a unit). Indeed. Is there any form of proposal or some alternative to the USES clause, that will keep all the imported symbol names qualified by some namespace name or by some prefix I choose ? Not that I know of. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden terminato...@gmail.com wrote: Hello As the language is currently specified, an identifier is searched in, and used from, the last unit in the USES clause that exposes that identifier. As some might know already, this exposes the user to future compatibility problems, stemming from the fact that the USES clause imports and open namespace into the user program. Imagine my perfectly tested scientific computations program uses two third-party units: Math and Trig. Currently only the Math unit exposes a log() function that computes the base e (that Euler number) logarithm of the given argument. All is so good and nice and I get promoted or I get to another project or to another company and leave the code on the repository. An year later a new version of Trig unit is available, the company promptly upgrades it and after some time someone else needs to make some changes to, or just re-compile for porting or other resons, the initial scietific computations program. Now Trig also exposes a new log() function, which computes the base 10 logarithm for its given argument. Now Trig appears last in the USES list, after Math. 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. Of course this is a particular case, and in the general case it is most likely I will get some compilation error, if a unit that appears later in the USES clause suddenly now defines a previous symbol, that I make use of in my program. But still, if the program never changes (on git/svn/cvs), it should still compile later, as it stands... 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 (I believe there is no equivalent feature in Pascal that imports only one symbol from a unit). Is there any form of proposal or some alternative to the USES clause, that will keep all the imported symbol names qualified by some namespace name or by some prefix I choose ? Something like: import System into sys, Math, Trigonometric into trig; and then I would need to use trig.actg() as the only possible way to refer to actg() function in the Trigonometric unit, and to use Math.log() for logarithm ? Yes, I know I can qualify names even now if I so choose, but I was thinking for a way to ensure that qualified names are the only possibility, and a way that will allow me some shorter qualification, because with the current qualified names, the qualified name can be really long. Thank you, Timothy Madden I feel your pain. A long time ago this topic was talked here, on the list, and many ideas were proposed... but none was accepted or because no one will implement it. I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end Simple, clean and easy. But I do not know how implement this on the compiler. IMHO, without changing the language, only the compiler could use simple names. All others third-party library -- even Lazarus -- should use prefixes in ALL identifiers in the unit, unfortunately. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. True, but using this sintaxe I can use an alias to the third-party units so, I can use my own names to reference identifiers that I can not change. The collision still can exists? Yes, but in that case the programmer would be wrong, not third-party unit names or because the compiler not helped. The third-party could use a better and bigger name like XyzNetSocket but I could use just net (uses XyzNetSocket as net), for example. IMHO this is more sophisticated than pure namespace. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... 2012/8/21 Marcos Douglas m...@delfire.net: On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. True, but using this sintaxe I can use an alias to the third-party units so, I can use my own names to reference identifiers that I can not change. The collision still can exists? Yes, but in that case the programmer would be wrong, not third-party unit names or because the compiler not helped. The third-party could use a better and bigger name like XyzNetSocket but I could use just net (uses XyzNetSocket as net), for example. IMHO this is more sophisticated than pure namespace. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 4:42 PM, Jorge Aldo G. de F. Junior jagf...@gmail.com wrote: 2012/8/21 Marcos Douglas m...@delfire.net: On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. True, but using this sintaxe I can use an alias to the third-party units so, I can use my own names to reference identifiers that I can not change. The collision still can exists? Yes, but in that case the programmer would be wrong, not third-party unit names or because the compiler not helped. The third-party could use a better and bigger name like XyzNetSocket but I could use just net (uses XyzNetSocket as net), for example. IMHO this is more sophisticated than pure namespace. Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... Well, a good idea but this is another thing... This is do not resolves the problem if I have a third-party unit with the same name that other. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 5:19 PM, Marcos Douglas m...@delfire.net wrote: On Tue, Aug 21, 2012 at 4:42 PM, Jorge Aldo G. de F. Junior jagf...@gmail.com wrote: 2012/8/21 Marcos Douglas m...@delfire.net: On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. True, but using this sintaxe I can use an alias to the third-party units so, I can use my own names to reference identifiers that I can not change. The collision still can exists? Yes, but in that case the programmer would be wrong, not third-party unit names or because the compiler not helped. The third-party could use a better and bigger name like XyzNetSocket but I could use just net (uses XyzNetSocket as net), for example. IMHO this is more sophisticated than pure namespace. Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... Well, a good idea but this is another thing... This is do not resolves the problem if I have a third-party unit with the same name that other. ...continue: If I can use an alias to ref an unit, the names could be bigger because I can ref them only using the alias. Extend the concept: if nevertheless we have same names in two libs (eg: foounit), we could use: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; IMHO, would be PERFECT. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
the alias is the fully qualified function name : myunit1.function1() myunit2.function2() you dont need alias, cause you cant have two units with the same name, so you have two different fully qualified function names. The warning would simply point out that there are two functions with the same name and parameters in the current scope, because thats the only possible conflict. Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... 2012/8/21 Marcos Douglas m...@delfire.net: On Tue, Aug 21, 2012 at 5:19 PM, Marcos Douglas m...@delfire.net wrote: On Tue, Aug 21, 2012 at 4:42 PM, Jorge Aldo G. de F. Junior jagf...@gmail.com wrote: 2012/8/21 Marcos Douglas m...@delfire.net: On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I proposed this sintaxe: uses my_long_unit_name as my; begin my.proc(); end This doesn't protect any better, since the new unit might also define my. True, but using this sintaxe I can use an alias to the third-party units so, I can use my own names to reference identifiers that I can not change. The collision still can exists? Yes, but in that case the programmer would be wrong, not third-party unit names or because the compiler not helped. The third-party could use a better and bigger name like XyzNetSocket but I could use just net (uses XyzNetSocket as net), for example. IMHO this is more sophisticated than pure namespace. Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... Well, a good idea but this is another thing... This is do not resolves the problem if I have a third-party unit with the same name that other. ...continue: If I can use an alias to ref an unit, the names could be bigger because I can ref them only using the alias. Extend the concept: if nevertheless we have same names in two libs (eg: foounit), we could use: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; IMHO, would be PERFECT. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 6:29 PM, Jorge Aldo G. de F. Junior jagf...@gmail.com wrote: the alias is the fully qualified function name : myunit1.function1() myunit2.function2() Yes, we know.. you dont need alias, cause you cant have two units with the same name, so you have two different fully qualified function names. Yes, we know too... but how prevent this using third-party libs? For example, what do you think if I have a project that have a file called lnet.pas? Can I use this identifier? I think so... WAIT, I can't because the lnet project already uses, right? But I didn't know before...ohh my... and now, I can't use this project because I will got a compiler error because cant have two units with the same name. Do you think this is right? Because of this conflict that I proposed the syntax: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; But this sintaxe is just to resolve a conflict, isn't default configuration, of course. The warning would simply point out that there are two functions with the same name and parameters in the current scope, because thats the only possible conflict. Yeah, I understood and I think this is a great idea (too). Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
