[fpc-devel] FPC Macros: Could it be used for unit aliases?

[Marcos Douglas B. Santos]

On Sun, Jun 24, 2018 at 4:06 PM, Sven Barth via fpc-devel
<fpc-devel at lists.freepascal.org> wrote:
> Am 24.06.2018 um 16:49 schrieb Marcos Douglas B. Santos:
>>
>> Hypothetically, let's suppose that Windows and Graphics unit belongs
>> to `FPC.RTL.` namespace, a "long name".
>> Using a syntax sugar to macros, I propose to implement the "as"
>> keyword in units declarations:
>>
>> === code begin ===
>> uses
>>     FPC.RTL.Windows as Win,
>>     FPC.RTL.Graphics as Graph;
>> var
>>    B1: Win.TBitmap;
>>    B2: Graph.TBitmap;
>> === code end ===
>>
>> if I understood right, the compiler "just" need to replace this syntax
>> to use macros:
>>
>> === code begin ===
>> uses
>>     {$macro on}
>>     FPC.RTL.Windows,
>>     {$define Win := FPC.RTL.Windows}
>>     FPC.RTL.Graphics as Graph;
>>     {$define Graph := FPC.RTL.Graphics}
>> var
>>    B1: Win.TBitmap;
>>    B2: Graph.TBitmap;
>> === code end ===
>>
>> In my company we are used to use namespaces like
>> `Acme.SysFoo.Finances.Billing.Utils.Classes` (just an example).
>> Depending on the context, I could code `uses ... as Billing;`
>> Using `Billing` as prefix for all interfaces/classes that has the same
>> names in others units.
>
> You can make use of default namespaces using -FN<x>.
>
> For your first example you'd use -FNFPC.RTL and then you could simply put
> the units Windows and Graphics into the uses sections.

Sorry, but I'm not talking about a global identifier. This could be
achieve using a long unit name, as Java developers do.
If we put the company name as a prefix for all units, I believe, it
may be very difficult to has a name conflict with another
projects/libraries.
However, the "issue" using this approach is that the code will be much
more verbose, if we need to use unit names as a prefix to solve some
name conflict, which could happens with classes that belongs to the
same project.

I'm talking about a local identifier per unit.
IMHO, to have both pros above — long names with no conflict; short
identifiers — we can use the idea of macros as you've already
explained to me.

> For your other example let it be said that with default namespaces you can
> use any part of the name to resolve ambiguities:
> E.g. with -FNAcme.SysFoo.Finances.Billing.Utils and a "uses Classes" (though
> I wouldn't recommend that one due to potential conflict with the RTL unit :P
> ) you could use any of the following to refer to the "Classes" unit:
>
> Classes
> Utils.Classes
> Billing.Utils.Classes
> Finances.Billing.Utils.Classes
> SysFoo.Finances.Billing.Utils.Classes
> Acme.SysFoo.Finances.Billing.Utils.Classes

IMO this is too ambiguous.
I've shown just an example. There are many other units with the same
prefix (or group of names). The only difference is the last part.
I will have "Classes" sufix in many others unit names.
E.g:
 Acme.SysFoo.Finances.Billing.Classes
 Acme.SysFoo.Finances.Billing.Utils.Classes

I need to think:
"Could I use just `Billing.Classes`?"
"Maybe `Finances.Billing.*` is better to prevents some name conflict?"

Instead, I prefer using fully qualified names and just adjust in some
contexts that *there is* already a conflict name.
In other words, `uses foo as bar;` will be use per unit. It is not to
intent "renaming" a unit name for all project as Delphi namespaces
approach uses.

> Other than that I think the task of reducing typing for this is better put
> into the hands of the code completion of a capable IDE.

It's not about reducing typing, but improve the readability of the code.
In the uses clause, I don't care if an unit gets a 100 chars length.
But inside the algorithm, it reduce the readability.

We can control these names and conflicts locally... it's only depends
on you now :)

Best regards,
Marcos Douglas