[fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Marcos Douglas]

On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev
<skalogryz.lists at gmail.com> wrote:
>
> On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas <md at delfire.net> wrote:
>>
>> On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev
>> <skalogryz.lists at gmail.com> wrote:
>> > Technical problem:
>> > * a unit name collision of two independent library code. Either library
>> > are
>> > using unit with the same name. The code in the conflicting units is
>> > different. Thus one library should use its own unit, the other should
>> > use
>> > its own.
>> > Since FPC allows to specify the search path for the whole compiled
>> > program,
>> > the second library used, will be using a wrong unit (from the first
>> > library), causing either compilation to fail or wrong code generated;
>> >
>> > Can anyone think of any logical problems with this feature:
>> > * allow any unit (or units under specified directories) to use their own
>> > "unit-search" paths, than defined for the project. In that case if a
>> > library
>> > has its own unit, the compiler will be using the library specific unit
>> > (by
>> > finding it in the library specific search path).
>> >
>> > From compiler point of view - it's only a matter of where to find the
>> > source
>> > code for the unit and how to name the resulting objects and object file.
>> > (names must not conflict, in case some units of a compiler project
>> > match);
>> > Linker, shouldn't have any issues as long as objects files were created
>> > properly;
>> > Debugging information - no problems here, since the source file name is
>> > specified explicitly and is typically full path;
>> >
>> > Limitations:
>> > * two units with the same name are not allowed to be used by any other
>> > unit
>> > at the same time
>> > uses unitA (from pathA), unitA (from pathB)  - not allowed;
>> > * RTTI collisions are not to be resolved by this feature;
>>
>> Complex...
>>
>> Think this:
>> /project/unit1.pas
>> /project/StrUtils.pas
>> /lib/StrUtils.pas
>>
>> ===code===
>> unit unit1;
>>
>> uses StrUtils; // local or Lib???
>> ===code===
>>
>> To compile the unit1.pas the compiler need to know where is
>> StrUtils.pas and whether to use /lib/StrUtils or /project/StrUtils,
>> right?
>> So, if we could to set a parameter to compiler saying:
>> fpc -ALIAS /lib/* TheLib
>>
>> Of course I invented the "-ALIAS" parameter.
>> So, returning to unit1, if we want to use the "local" StrUtils unit,
>> just use the name "StrUtils". But if we want to use the Lib's
>> StrUtils, then:
>>
>> ===code===
>> unit unit1;
>>
>> uses TheLib.StrUtils;
>> ===code===
>>
>> What do you think?
>>
>> Best regards,
>> Marcos Douglas
>
>
> Hmm, let me extend your example:
>
> /project/unit1.pas
> /project/StrUtils.pas
> /lib/StrUtils.pas
> /lib/ExtraUtils.pas
>
> ---code---
> unit ExtraUtils;
>
> uses StrUtils; // assumed  library StrUtils, not project
> ===code===
> However, since StrUtils is present in project directory, it will be used
> instead, causing compilation errors.
>
> compiling with
> fpc -ALIAS /lib/* TheLib
>
> won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils

Well, is more common to use just ppu files to not compile these files
every compilation. So, the Lib was already compiled using your own
files, all in the same directory or tree.

> Your thoughts?
>

My propose is to compile our projects, using 3rd-party sources (libs),
without names conflict.
Somebody used, eg, UnicodeUtils as an unit name in a lib... this
should be Ok because the programmer do not know all lib names in the
world and prefixes. So, he used a good name for your own sources.

The problem is "good name for an unit" because I also use good names!
So, how can I know all unit names for all libs around the world? I
can't use UnicodeUtils? FPC already use? Maybe Lazarus? I do not know.
So, IMHO, we need a way to can compile these lib sources without
trying to predict the future on the names of units.

> My proposal looks like this:
> -SEARCH
>
> fpc -SEARCH/program/unit1.pas@/lib/
>
> Causing fpc to look for units at "Libs" first when compiling
> "/program/unit1.pas"
> No changes in any source code necessary.
> With the swicth present
> ---code---
> unit unit1
>
> uses StrUtils; // strutils from lib
> ===code===
>
> thanks,
> Dmitry

This works only if you don't want use StrUtils of your project and,
IMHO, this is more complex solution. You will need to tell the
compiler which unit of your project that compiles using an unit in
another place that uses the same unit name you already uses in your
project.

The "rules" that I proposed are:
1- Sources in the same directory and/or own tree are compiled using
the "real names" of units.
2- Sources in another tree are (optional) compiled using an "alias".
These alias are used as a prefix to real names of units.

See. You do not create a project and put their sources out of the tree.
The only reason, IMHO, you need to use sources out the main project
tree is to use a lib (3rd-party).

We need dynamic namespaces.

Regards,
Marcos Douglas