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

[Sven Barth]

Am 22.08.2012 12:37, schrieb Timothy Madden:
> On 08/22/2012 09:57 AM, Marco van de Voort wrote:
>> In our previous episode, Marcos Douglas said:
> [...]
>>
>>>> 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. ;-)
>
> This is necessary in order to guarantee thare can be no conflicts
> whatsoever. No matter how many units you want to USE in your program, no
> matter what versions of the units.
>
> It is not that bad, python uses that from the start. You must call
> os.path.basename(), and there is not way for you to call basename()
> directly (well, there is one, but they have taken special measures for
> it, so no name conflicts are possible).
>
> But for this to work, I need a way to alias the importing module,
> because not all units have a 2-letter name like "os", for example I need
> something like:
>   USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas'
>
>
> Of course I will not remove the existing behavior for USES, that is
> programmers can still say:
>   USES charset, matrix, socket;
> and they get the behaviour they know.
>
> But if the programmer says:
>   USES charset AS cs, matrix AS matrix, socket AS socket;
> than no symbols are made directly visible, and all of them need their
> prefix now (one of cs. or matrix. or socket. ). These prefixes are
> chosen by the programmer so thay may not create conflicts, as long as
> programmer sticks to the new form of USES.
>
> If both forms of USES are intermixed, like
>     USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket;
> than there is a chance that prefix cs will conflict with some unit1.cs
> symbol (either now or in a future version of unit1, or unit2). In this
> case I think it is appropriate to make the prefix "cs.", introduced by
> "charset AS cs", to have precedence over unit1.cs. This is because the
> programmer must use the prefix "cs." a lot in the program ((s)he has no
> choice, since the prefix is the only way to access simbols from unit
> charset).

Feel free to extend the compiler with such a feature and provide a 
patch. If you give enough thought to it, provide enough tests and ensure 
that this won't influence old code too much the chances that your patch 
gets applied shouldn't be too bad.

If you don't implement it... well... it may sound harsh, but: there are 
already many (partly more important) features that we need/want to 
implement...

Note: I definitely prefer your solution instead of a warning ;)

Regards,
Sven