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

[Marcos Douglas]

On Mon, Nov 4, 2013 at 1:31 PM, Dmitry Boyarintsev
<skalogryz.lists at gmail.com> wrote:
> On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas <md at delfire.net> wrote:
>>
>> On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev
>> <skalogryz.lists at gmail.com> wrote:
>> > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas <md at delfire.net> wrote:
>> >>
>> >> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is
>> >> not a subdirectory of lib then the "otherlib needs to be compiled
>> >> using a ALIAS:
>> >> -ALIAS=TheLib at lib\*
>> >
>> > Ah, yes, you've mentioned the necessity for two steps compilation.
>> > (compile a package first and then compile the program).
>
>
>>
>> This is not required is optional.
>
> It is required, otherwise a wrong "StrUtils" might be used.
> Or let me paraphrase that, it is required to recompile it at least once.

I meant this is not required for your own units.


>> > Which brings the necessity for external "tools" (similar to make files)
>> > or
>> > an IDE must be smart enough to handle them.
>> > (please note "an IDE", thus not refer erring to Lazarus specifically).
>>
>> No one compiles programs using line code options. Everybody uses a IDE
>> or script for do it.
>> But I did not see what the problem because it is only a new argument
>> for the compiler.
>
> a scripts or an IDE would need to be adjusted then.  It's not a big deal,
> but it's a change.

As I said before, IMHO, no one compiles programs using line code options...


>> >> But, for me, doesn't any sense the otherlib does not know the lib's
>> >> sources.
>> >
>> > Otherlib knows about "lib"s sources - it knows that there should be
>> > "StrUtils" unit.
>> > However, it doesn't know anything about there the "StrUtils" is located,
>> > as
>> > well as it doesn't care what to do with other files of the project. It's
>> > compilers job.
>>
>> I know. When as said "Otherlib do not known about Lib" I was talking
>> about source paths.
>
> Well a lib, shouldn't care about paths at all, it's compiler's job.

As I said... I agree.


>> If you do not change the unit names, how you can use StrUtils from
>> Lib, OtherLib and program in a same unit?
>
> You definitely can't. I stated that as a limitation.
> That's not a purpose of the tag anyway, the purpose is to resolve
> uncontrolled unit name collisions (typically introduced by changes into a 3d
> party lib).

If you consider my proposal, is definitely possible.
IMO, doesn't exist advantages if we couldn't use two units (same name,
but not same project) in the same code, at the same time.


> If you need to mix a code from 2 units that share the same name, you'd need
> to create a wrapping unit.
>
> ---code---
> unit LibStrUtils
>
> uses StrUtils;
>
> interface
>
> var
>   procedure DoStrUtil = StrUtils.DoStrUtil;
> ---code---
> unit Unit3;
>
> uses StrUtils, LibStrUtils;
>
> ==code==
>
> program\unit1.pas (uses lib/StrUtils.pas)
> program\StrUtils.pas
> program\unit2.pas (uses program/StrUtils.pas)
> program\unit3.pas (uses program/StrUtils.pas)
> program\LibStrUtils.pas (uses lib/StrUtils.pas)
>
> lib\StrUtils.pas
> otherlib\ExtraUtils.pas (uses lib/StrUtils.pas)
> --
> fpc
> -SEARCH program/unit1.pas lib/StrUtils.pas   (point unit1 to use
> lib/StrUtils explicitly)
> -SEARCH program/LibStrUtils.pas lib/StrUtils.pas   (point unit1 to use
> lib/StrUtils explicitly)
> -SEARCH otherlib/ lib/ (point "otherlib" units to use any unit from "lib"
> first, if found)
> -Fulib
> -Fuotherlib
> program.pas

Sorry, but this is boring.
Do you not agree that is much better propose a solution to be possible
to use two -- or more -- units that have the same name but works
together at the same project?

Regards,
Marcos Douglas