[fpc-devel] Namespaces [was: is that intended? private type section in classes versus visibility]

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:
> Op 2010-07-26 02:45, Hans-Peter Diettrich het geskryf:
>> How should that work? How to distinguish between <std>utils.pas and 
>> <other>utils.pas, in "using utils;"?
> 
> I'm thinking in the line of working with something like Lazarus Packages.
> This is not limited to Lazarus only though. When I talk about a "lazarus
> package" I mean a set of code (units) that act as one "library" in a sense.
> Lets use a Lazarus Package (*.lpk) as a simple example.
> 
> We have a lazarus package named:  fpgui_toolkit.lpk
> Compile that package with '-namespace=fpgui' and all compiled units are
> output to a 'lib' directory.

Looks nice, but I doubt that it will work. What about units, added 
implicitly by dependencies? What if such a used unit will/shall become 
part of another package, later?


> Now we have a project that uses that Lazarus Package as a dependency,
> referencing the already compiled units directory 'lib' from the
> fpgui_toolkit.lpk package (this means compiling this project doesn't need
> to compile the fpGUI toolkit units - they are already compiled). Now lets
> say this project also contains a utils.pas (fpgui_toolkit.lpk also
> contained a utils.pas unit). Now if this project wants to reference the
> utils.pas from fpGUI package, it would use the <namespace>.<unitname>
> format in the uses clause. If this project only used 'uses utils;' then it
> would reference the utils.pas of this project (part of the "global"
> namespace which takes priority" because this project was not compiled with
> a -namespace= parameter.) and not of the utils.pas in the fpgui_toolkit
> package.

When utils.pas will become a member of an RTL package, every unit using 
utils will have to be updated, in order to reflect the new rtl.utils 
unit. Then we are deeper in mess than we currently are, without namespaces.


> Alternatively, all
> units must define the namespace they belong to, inside the unit on the
> 'unit' line. Then you don't need to pre-compile 3rd party units.

Again back to the current state: chance for duplicate namespace names, 
or required renaming or editing of third party units - as far as source 
code is available at all.


If ever, I'd agree about (project wide) symbolic names for library 
directories. Then the file location is given once, in the program or 
package settings (search path), easily adoptable to any installation, 
and then a package unit can be qualified (fully optional) by the package 
name, to override the current unit search strategy.

DoDi