[Lazarus] FPReport file names

[Ondrej Pokorny]

On 13.09.2017 15:33, Mattias Gaertner via Lazarus wrote:
>> Also were is there an ambiguity anyway (given all units are used with their
>> full name)? The compiler reads (in my above example) the token sequence ID
>> Point ID and thus can find the unit without any backtracking just as for
>> ordinary methods. Even once the default namespace option is added that
>> won't change as the compiler will simply test all provided namespaces as
>> prefixes and then the name as is. It's just a longer list of names than
>> usually to test for.
> Let's say you have 'a.b.c.d'. Before namespaces the compiler could
> simply resolve a, then b, then c and finally d.
> With namespaces the compiler has to read the full 'a.b.c.d',
> then search for a.b.c, then a.b, then a and then resolve the rest as
> before.

I think you are wrong. I didn't study how the compiler resolves the 
identifiers internally, but when I developed dotted unit support for 
CodeTools I did it so: I register all namespaces and subnamespaces from 
known units (for uses clause) and used units (for implementation code) 
and resolve the identifiers from left to right - easy and how it's 
always been.

In your example you always know if 'a' is a namespace or an identifier. 
The identifier always wins agains a namespace:

unit ns1.Unit1;
interface
var
   A: string;
   ns1: Integer;
implementation
initialization
   ns1.Unit1.A := 'a'; // << error illegal identifier
end.

unit ns1.Unit2;
interface
var
   A: string;
   ns1: Integer;
implementation
uses
   ns1.Unit1; // error: duplicate identifier (bug in CodeTools: they 
don't show an error here because they don't test agains identifier in 
uses clause- but the compiler is correct)
initialization
   ns1 := 1;
end.

Everything looks like the compiler uses the same algorithm -> it first 
resolves a then b then c and so on, it doesn't need to go backwards.

Ondrej