[fpc-pascal] How to avoid namespace name clashes after
Marco van de Voort
marcov at stack.nl
Wed Aug 22 08:57:56 CEST 2012
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:
> 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
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.
More information about the fpc-pascal