[fpc-pascal] Re: How to avoid namespace name clashes after USES ?

[Marco van de Voort]

In our previous episode, Timothy Madden said:
> Very ingeniuos, I believe this is as close to a solution as I can get
> for now.
> 
> But there are still a few probles I can see:
>    - there is no way to "prefix" symbols within a unit, that I know of.

Some languages related to pascal and maybe even other pascal dialects have 
ways to import an unit/module qualified. FPC doesn't.

E.g. under modula2

IMPORT IO;

will import everything from IO qualified.

Unqualified importing is possible, but only for specific symbols:

FROM IO IMPORT WrStr;

allows to use WrStr without IO.

functions to be exported unqualified when imported.

E.g.

an 

EXPORT UNQUALIFIED WrStr;

in module IO would cause the first statement to add WrStr both as "WrStr"
and IO.WrStr to the scope.


Note that FPC has other ways to disambiguate thoug. Since scope is stack
based in Wirthian languages, order of units in the uses clause matters for
which symbol is visible when similar named symbols clash.

>      Symbols may only be prefixed by the unit name directly. Is there a
>      sort of a "namespace" in Pascal ?

An unit/module is a concept that includes a namespace. (since you can
qualify identifiers with unitname)

>    - I find it even more tedious to do the same thing with the System
>      unit or the standard Pascal units.

Why do you feel the need for a prefix? The rare clashes can be easily dealt
with by uses list ordering and qualifying with unitname.

The only other thing I can imagine is that you might want to confine
importing units with gigantic numbers of symbols (like Windows) into general
units/modules, but confine that more OS specific and encapsulation units.

This because such units of course increase the chance of clashes
significantly, and while that can be remedied as above, in this case it is
better to avoid it.
 
> And then, if wrapper unit publicly uses the third-party unit, doesn't
> that mean that all symbols in the thrid-party unit are now automatically
> exposed and public in the wrapper unit ?

Not standard no. If you "uses" an unit you only import the symbols from
that unit itself, not what that unit imports.