resolving namespace conflicts via project ? [Re: alternative aliases [Re: [fpc-devel] Re: [fpc-pascal] Re: Ideas for namespace implementation]]
fpc at mfriebe.de
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