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. > 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. > > 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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
