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

[Marcos Douglas]

On Sun, Nov 3, 2013 at 10:22 PM, Dmitry Boyarintsev
<skalogryz.lists at gmail.com> wrote:
> On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas <md at delfire.net> wrote:
>>
>> Wrong. Do not breaks the compiler backward compatibility.
>> I said " in the same directory and/or own tree", ie, in the same
>> directory and subdirectories. For these cases, the compiler do not
>> need changes.
>
> The compiler doesn't use a unit's same directory for searching units. It is
> using project's file directory for searching and then any directories
> referenced is -Fu switch.

Of course the project's file determinate the searcher... that's what I
meant before. Sorry my english.

> Thus the same list of search directories is used for any unit in the project
> (and that's causing the requirement to have all unit names unique per
> project)

Yes.

>> First, if you have a lib that have dependencies to another lib, you
>> have to provide all sources together -- in the same directory or
>> subdirectories.  For this case just use the rule #1.
>> But, if you did not provide the sources for the other lib, the user
>> will need to define the "ALIAS" to the lib that have dependencies
>> before compile it (package). For this case use the rule #2.
>
> Changing the structure of a project is a big NO. For a number of reasons:

There is no changes! The change is a new parameter (OPTIONAL) in the
compiler... just this.

> * a compiler change should never force a developer to make any major changes
> in the project sources or structure;

Again, I not proposed any changes in "project sources of structure".

> * it might be impossible to merge two different components into the same
> directory or sub directory, because of the conflicting file names;

But this is already impossible today!

> * the external tools (i.e. SVN) might require two components be in a
> separate folders (i.e. for syncing sources);

Nothing will be change to SVN, Git, whatever...

> -so I'd removing rule #1 as a solution here.
> As well as rule #2, since it's not an option to change 3d party code (even
> just to introduce an alias reference). Don't forget that you've mentioned it
> earlier yourself.
The "rule #1" is the current rule!
Using the "rule #2" you do not need to change 3rd-party codes! This
rule is to provide the programmer exactly the oposite: provide to you
to use 3rd-party without change anything!

Thanks,
Marcos Douglas