resolving namespace conflicts via project ? [Re: alternative aliases [Re: [fpc-devel] Re: [fpc-pascal] Re: Ideas for namespace implementation]]

Martin fpc at
Tue Jul 27 14:21:07 CEST 2010

On 27/07/2010 12:42, Martin wrote:
> Reffering to 
> Due to the missing concept of one "package unit", that stores settings 
> for all units in that directory, there is also a question where to 
> store such settings.
> Currently one way would be to replicate them to each and every unit in 
> the directory => a real bad idea, because nothing gurantees that the 
> setting will be equal for the whole package....
> If there was one "package unit", that could be used to store setting 
> for all units, a unit could have a UUID in addition to a namespace => 
> Then the project could map a new alias to such a UUID.

Having written this, here is an alternative idea.

Scrapping the -Fu extension (though that could stay, as an additional way).

In absence of a "package" declaration file, each "package" (as in 
"collection of units in a folder" ), could have a local  fpc.cfg file
- This file would not be allowed all kind of settings (since not all 
settings would make sense)
- this file could:
-- Specify a namespace for the package
-- Specify a UUID for the package

the project could also have such an fpc.cfg config (maybe things could 
be defined in the main program file? but they may need to be known, if 
compiling any of the units...)
The program's fpc.cfg file could:
-- override namespaces, by referring to the UUID
    So namespace conflicts can be solved per project

   uses Foo in NamesSpaceBar as BarFoo;

would stay as proposed


More information about the fpc-devel mailing list